Re: [IPsec] [Technical Errata Reported] RFC8221 (7828)
I was looking at it and was skeptical about it ;-). Thanks Rebecca. Yours, Daniel On Wed, Feb 28, 2024 at 7:13 PM Rebecca VanRheenen wrote: > FYI - this report has been deleted as junk. > > Thank you. > > RFC Editor/rv > > > > On Feb 28, 2024, at 4:03 PM, RFC Errata System < > rfc-edi...@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC8221, > > "Cryptographic Algorithm Implementation Requirements and Usage Guidance > for Encapsulating Security Payload (ESP) and Authentication Header (AH)". > > > > -- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid7828 > > > > -- > > Type: Technical > > Reported by: Mccoy stevens > > > > Section: Global > > > > Original Text > > - > > National > > > > Corrected Text > > -- > > National > > > > Notes > > - > > I > > > > Instructions: > > - > > This erratum is currently posted as "Reported". (If it is spam, it > > will be removed shortly by the RFC Production Center.) Please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > will log in to change the status and edit the report, if necessary. > > > > -- > > RFC8221 (draft-ietf-ipsecme-rfc7321bis-06) > > -- > > Title : Cryptographic Algorithm Implementation > Requirements and Usage Guidance for Encapsulating Security Payload (ESP) > and Authentication Header (AH) > > Publication Date: October 2017 > > Author(s) : P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. > Kivinen > > Category: PROPOSED STANDARD > > Source : IP Security Maintenance and Extensions > > Area: Security > > Stream : IETF > > Verifying Party : IESG > > > > ___ > 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] IANA registries and WESP
Just in case, this has not been reported earlier, I have the impression WESP should be indicated as an IPv6 Header Extension in [1]. If that is the case we should also add it there in the Header Extension registry in [2]. If we were to do some clean up [1] has a few missing keywords, and keywords from [1] should also be reported in [2] - or [2] completely removed. Yours, Daniel [1] https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml [2] https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml#ipv6-parameters-1 -- 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
Hi Hannes, Sure, we will consider that feedback when updating the draft. Thanks! Yours, Daniel On Tue, Dec 26, 2023 at 3:42 AM Hannes Tschofenig wrote: > Hi Daniel, > > > thanks for the additional background. > > > I would suggest avoid talking about IoT in the documents and take the use > case description from our email conversation instead. This will provide a > more convincing story for the functionality you are suggesting. > > > Ciao > > Hannes > > > Am 24.12.2023 um 22:18 schrieb Daniel Migault: > > Hi Hannes, > > I actually do not mind at all whether the Base Stations are considered as > an IoT or not. I said "could be" in the sense that is a very specific > hardware dedicated to very specific tasks looking closely at the resources > engaged in its transactions to meet the latency requirements. Obviously > anyone looking at compressing the number of bytes is paying attention to > the resources. I agree though they might also be quite far from use cases > with low battery, few packets > > I think the confusion comes from the fact that the annexes of the current > document are only focused on IoT. These are examples we started with quite > some time ago, but these are not anymore the use case for which I have > cycles to drive this effort. That said, I still think the protocol can be > used for other use cases than the base station use case - including any IoT > and non IoT related use case. I am actually quite happy that we are > not addressing a single use case. > > Yours, > Daniel > > > > > On Sun, Dec 24, 2023 at 8:47 AM Hannes Tschofenig < > hannes.tschofe...@gmx.net> wrote: > >> Hi Daniel, >> >> >> I think we are on the same page on a number of items already. >> >> There is only this "base station is an IoT use case" issue left. >> >> >> Could you explain under what circumstances you consider a base station >> being an IoT device (or even a constrained IoT use case)? >> >> Ciao >> Hannes >> >> Am 17.12.2023 um 16:45 schrieb Daniel Migault: >> >> Hi Hannes, >> >> Please find my responses inline. >> >> Yours, >> Daniel >> >> On Tue, Dec 12, 2023 at 9:45 AM wrote: >> >>> Hi Daniel, >>> >>> >>> >>> thanks for your response. See my response below. >>> >>> >>> >>> *From:* Daniel Migault >>> *Sent:* Dienstag, 12. Dezember 2023 15:20 >>> *To:* Hannes Tschofenig >>> *Cc:* Hannes Tschofenig ; >>> Carsten Bormann ; Tero Kivinen ; >>> ipsec@ietf.org; s...@ietf.org >>> *Subject:* Re: [IPsec] WG Adoption calls for >>> draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension >>> >>> >>> >>> Hi Hannes, >>> >>> >>> >>> Seems I did not click "sent" yesterday. Please see my response inline. >>> >>> >>> >>> Yours, >>> >>> Daniel >>> >>> >>> >>> On Mon, Dec 11, 2023 at 12:02 PM Hannes Tschofenig < >>> hannes.tschofe...@gmx.net> wrote: >>> >>> Hi Daniel, Hi all, >>> >>> >>> >>> don't get me wrong: I am trying to be helpful. >>> >>> >>> >>> This is how I am reading your comments. >>> >>> 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. >>> >>> >>> >>> In our case, we want to "compress" / "decompress" IPsec traffic for our >>> base stations. These could be seen as IoT in the sense that they are under >>> heavy constraints... but I admit these are not sensors with a battery. >>> >>> >>> >>> [Hannes] Base Stations are not constrained IoT devices (see RFC 7228 >>> terminology). I assume that the base stations originate or terminate the >>> traffic and the traffic being protected is some signaling protocol. If so, >>> your co-workers, Magnus & John, who working on SCTP in the TSVWG, tell us >>> that IPsec/IKEv2 is being phased out and replaced by TLS/DTLS. There is a >>> design team working on this topic in the TSVWG. Hopefully your drafts are >>> not taken
Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension
Hi Hannes, I actually do not mind at all whether the Base Stations are considered as an IoT or not. I said "could be" in the sense that is a very specific hardware dedicated to very specific tasks looking closely at the resources engaged in its transactions to meet the latency requirements. Obviously anyone looking at compressing the number of bytes is paying attention to the resources. I agree though they might also be quite far from use cases with low battery, few packets I think the confusion comes from the fact that the annexes of the current document are only focused on IoT. These are examples we started with quite some time ago, but these are not anymore the use case for which I have cycles to drive this effort. That said, I still think the protocol can be used for other use cases than the base station use case - including any IoT and non IoT related use case. I am actually quite happy that we are not addressing a single use case. Yours, Daniel On Sun, Dec 24, 2023 at 8:47 AM Hannes Tschofenig wrote: > Hi Daniel, > > > I think we are on the same page on a number of items already. > > There is only this "base station is an IoT use case" issue left. > > > Could you explain under what circumstances you consider a base station > being an IoT device (or even a constrained IoT use case)? > > Ciao > Hannes > > Am 17.12.2023 um 16:45 schrieb Daniel Migault: > > Hi Hannes, > > Please find my responses inline. > > Yours, > Daniel > > On Tue, Dec 12, 2023 at 9:45 AM wrote: > >> Hi Daniel, >> >> >> >> thanks for your response. See my response below. >> >> >> >> *From:* Daniel Migault >> *Sent:* Dienstag, 12. Dezember 2023 15:20 >> *To:* Hannes Tschofenig >> *Cc:* Hannes Tschofenig ; >> Carsten Bormann ; Tero Kivinen ; >> ipsec@ietf.org; s...@ietf.org >> *Subject:* Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp >> and draft-mglt-ipsecme-ikev2-diet-esp-extension >> >> >> >> Hi Hannes, >> >> >> >> Seems I did not click "sent" yesterday. Please see my response inline. >> >> >> >> Yours, >> >> Daniel >> >> >> >> On Mon, Dec 11, 2023 at 12:02 PM Hannes Tschofenig < >> hannes.tschofe...@gmx.net> wrote: >> >> Hi Daniel, Hi all, >> >> >> >> don't get me wrong: I am trying to be helpful. >> >> >> >> This is how I am reading your comments. >> >> 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. >> >> >> >> In our case, we want to "compress" / "decompress" IPsec traffic for our >> base stations. These could be seen as IoT in the sense that they are under >> heavy constraints... but I admit these are not sensors with a battery. >> >> >> >> [Hannes] Base Stations are not constrained IoT devices (see RFC 7228 >> terminology). I assume that the base stations originate or terminate the >> traffic and the traffic being protected is some signaling protocol. If so, >> your co-workers, Magnus & John, who working on SCTP in the TSVWG, tell us >> that IPsec/IKEv2 is being phased out and replaced by TLS/DTLS. There is a >> design team working on this topic in the TSVWG. Hopefully your drafts are >> not taken over by the attempts to move telco infrastructure implementations >> into the cloud. >> > > > I am fine with the base station not being IoT - I said "could". > > The interfaces we want to use diet-esp are fronthaul or sidehaul related > in our case are the Lower Layer Control (LLS), the low latency coordination > interface between RAN Compute basebands (E5 or Elastic RAN in LTE). It is > correct that these interfaces include the user plan. > On the other hand, I am pretty sure my co-workers did not mean to say so > and it is correct that DTLS may be used on on the midhaul and inter > Centralized Units interfaces such as CU-UP/CU-CP (E1), DU/CU-UP (F1-C), > DU/CU-UP(F1-C), CU-CP/CU-CP (Xn-C), CU-CP/AMF (N2). > > >> >> >> The advantage of using SCHC is that there is a SCHC protocol code points >> so we can have different layers of compressions and use the same framework >> for all layers (including applications). ESP is only one layer. The >> implementation of course need
Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension
Hi Hannes, Please find my responses inline. Yours, Daniel On Tue, Dec 12, 2023 at 9:45 AM wrote: > Hi Daniel, > > > > thanks for your response. See my response below. > > > > *From:* Daniel Migault > *Sent:* Dienstag, 12. Dezember 2023 15:20 > *To:* Hannes Tschofenig > *Cc:* Hannes Tschofenig ; > Carsten Bormann ; Tero Kivinen ; > ipsec@ietf.org; s...@ietf.org > *Subject:* Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp > and draft-mglt-ipsecme-ikev2-diet-esp-extension > > > > Hi Hannes, > > > > Seems I did not click "sent" yesterday. Please see my response inline. > > > > Yours, > > Daniel > > > > On Mon, Dec 11, 2023 at 12:02 PM Hannes Tschofenig < > hannes.tschofe...@gmx.net> wrote: > > Hi Daniel, Hi all, > > > > don't get me wrong: I am trying to be helpful. > > > > This is how I am reading your comments. > > 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. > > > > In our case, we want to "compress" / "decompress" IPsec traffic for our > base stations. These could be seen as IoT in the sense that they are under > heavy constraints... but I admit these are not sensors with a battery. > > > > [Hannes] Base Stations are not constrained IoT devices (see RFC 7228 > terminology). I assume that the base stations originate or terminate the > traffic and the traffic being protected is some signaling protocol. If so, > your co-workers, Magnus & John, who working on SCTP in the TSVWG, tell us > that IPsec/IKEv2 is being phased out and replaced by TLS/DTLS. There is a > design team working on this topic in the TSVWG. Hopefully your drafts are > not taken over by the attempts to move telco infrastructure implementations > into the cloud. > I am fine with the base station not being IoT - I said "could". The interfaces we want to use diet-esp are fronthaul or sidehaul related in our case are the Lower Layer Control (LLS), the low latency coordination interface between RAN Compute basebands (E5 or Elastic RAN in LTE). It is correct that these interfaces include the user plan. On the other hand, I am pretty sure my co-workers did not mean to say so and it is correct that DTLS may be used on on the midhaul and inter Centralized Units interfaces such as CU-UP/CU-CP (E1), DU/CU-UP (F1-C), DU/CU-UP(F1-C), CU-CP/CU-CP (Xn-C), CU-CP/AMF (N2). > > > The advantage of using SCHC is that there is a SCHC protocol code points > so we can have different layers of compressions and use the same framework > for all layers (including applications). ESP is only one layer. The > implementation of course needs compression/decompression to be integrated > into IPsec. In our case mostly to adapt data structures accordingly and > perform the actual compression / decompression. Suppose one field is > removed. Some implementations build that field and remove it, others may > simply not add that field. Doing one or the other depends on which hardware > / software you are using. > > > > [Hannes] Your use case makes sense to me (if IPsec is still going to be > used in this environment in the future). You should maybe add text about > this use case to your document. This would provide a lot of extra context > for the reader. > I agree. This context is currently not being mentioned as we were mostly focused on the profile itself, but we will add some context. > The feedback on the list in response to the call for adoption was > confusing to me. Someone was saying “I could use it for ANIMA” and others > said “I could use it for LPWAN”. I don’t believe those use cases are > realistic. > > > > 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. > > > > For ESP, I have in mind wireguard performs 10 % / 15 % better in terms of > throughput for Chacha and AES-GCM, but I do not know enough to tell if this > is due to a specific setting or whether there is an implementation/systems > reasons for it. I hardly see the packet format being an issue but of course > I might be wrong. Of course if one can improve ESP we should do it and that >
Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension
Hi Hannes, Seems I did not click "sent" yesterday. Please see my response inline. Yours, Daniel On Mon, Dec 11, 2023 at 12:02 PM Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi Daniel, Hi all, > > > don't get me wrong: I am trying to be helpful. > > > This is how I am reading your comments. > 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. > In our case, we want to "compress" / "decompress" IPsec traffic for our base stations. These could be seen as IoT in the sense that they are under heavy constraints... but I admit these are not sensors with a battery. The advantage of using SCHC is that there is a SCHC protocol code points so we can have different layers of compressions and use the same framework for all layers (including applications). ESP is only one layer. The implementation of course needs compression/decompression to be integrated into IPsec. In our case mostly to adapt data structures accordingly and perform the actual compression / decompression. Suppose one field is removed. Some implementations build that field and remove it, others may simply not add that field. Doing one or the other depends on which hardware / software you are using. > 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. > > > For ESP, I have in mind wireguard performs 10 % / 15 % better in terms of throughput for Chacha and AES-GCM, but I do not know enough to tell if this is due to a specific setting or whether there is an implementation/systems reasons for it. I hardly see the packet format being an issue but of course I might be wrong. Of course if one can improve ESP we should do it and that is part of the evolution of ESP. > Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2 work well > on Linux-based IoT devices (*) > It would be interesting to understand what you think should be improved with the current IPsec/IKEv2. We have defined minimal versions of IKEv2/ESP that go into the simplification of the code. I think we could do more to ease the configuration, and probably the yang model that the WG are a good start - at least we are thinking of leveraging from these. > > 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 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. >> &
Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension
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
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 call for draft-mglt-ipsecme-ikev2-diet-esp-extension
I support the adoption as an author, this extension agrees on the necessary parameters to proceed to the compression so it is closely related to the previous document. Yours, Daniel On Mon, Nov 27, 2023 at 1:35 PM Tero Kivinen wrote: > This is two week adoption call for > draft-mglt-ipsecme-ikev2-diet-esp-extension. 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 > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-mglt-ipsecme-diet-esp
As an author I am supporting the adoption. We will closely collaborate with at least the SCHC WG cced as the compression framework uses SCHC. Yours, Daniel On Mon, Nov 27, 2023 at 1:34 PM 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 > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
I support the draft to be moved forward. some nits: """ 2. Performance bottlenecks There are a number of practical reasons why most Implementations have ... """ """ As per RFC 7296 """ Should we move section 8 into the appendix instead of removing the section ? I am also interested in the performance benchmark if it is available. Yours, Daniel On Mon, Nov 13, 2023 at 5:32 AM Sahana Prasad wrote: > Hello, > > I've read the draft and support its adoption. > > Specifically, we (at Red Hat) have use cases where customer to data center > links > see performance penalties for enabling IPsec on these > connections. We've been looking at how to fix this and this draft > seems to be a solution for our use case. > > Thank you, > Regards, > Sahana Prasad > > On Sun, Nov 12, 2023 at 10:15 PM Yoav Nir wrote: > >> Hi. >> >> I’ve read the draft. Overall, it’s similar to a non-standardized solution >> we did at Check Point several years ago, so I agree that it is a solution >> that works. Of course, since there *are* a bunch of working >> implementations, that is not particularly insightful. >> >> With a lot of flows, it’s likely that in most situations the number of >> parallel SAs is going to be about the same as the number of “resources”. >> The text in section 4 does mention the issue of having peers with a >> different number of CPUs. In practice these can be very different. It’s not >> unheard of to have a center office with dozens of CPUs working with a >> branch office machine with one. The way this protocol seems to work is that >> the center office will attempt to create dozens of SAs, only to be stopped >> by the branch office which at some point will return the TS_MAX_QUEUE >> notification. I’m not a big fan of creating as many SAs as you can until >> the peer fails you, but the alternative would be to pre-negotiate the >> ts_max_queue value. >> >> A couple of editorial comments: >> - Although it is implied, it should be stated explicitly that >> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As some >> child SAs get deleted and perhaps not rekeyed if they’re idle, if traffic >> picks up again, new child SAs with these TS can be created until the peer >> again blocks you with a TS_MAX_QUEUE. >> - With a single SA pair per TS, implementations can expect that all >> packets in a flow (such as a TCP connection) will go through the same SA >> pair. This is especially important in implementations that are combined >> with firewalls. I think we need explicit text that says packets for any >> flow may come on any of the SAs from the logical group of child SAs. >> Perhaps: >> >> “implementations MUST NOT assume that all packets of a particular flow >> will be encrypted with a particular SA in the logical group of child SAs. >> ” >> >> Yoav >> >> >> >> On 25 Oct 2023, at 1:40, Tero Kivinen wrote: >> >> This will start three week working group laste call for >> draft-ietf-ipsecme-multi-sa-performance. The working group last call >> will end at 2023-11-15. >> >> Please review the document and send comments to the list if you think >> it is ready for publication. >> -- >> 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 >> > ___ > 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] wesp discussion
Hi, Regarding the need to have non encrypted text in the esp packet, we had a use case a few years ago for tunnels such as Geneve. NSH may also be something that would need such a property. At that time I proposed something very similar to ESP. I think that is a useful feature to have to enable securing what is currently not secured at all. https://www.ietf.org/archive/id/draft-mglt-nvo3-geneve-security-architecture-00.txt https://www.ietf.org/archive/id/draft-mglt-nvo3-geneve-authentication-option-00.txt https://www.ietf.org/archive/id/draft-mglt-nvo3-geneve-encryption-option-00.txt Yours, Daniel -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Agenda for IETF 118
Hi Laurent, Sure. I intend to work on it during the hackathon. Yours, Daniel On Tue, Oct 31, 2023 at 4:15 AM Laurent Toutain < laurent.tout...@imt-atlantique.fr> wrote: > Hi Daniel, > > What about working on that at the hackathon. In San Francisco we started > working on it and we got good results, unfortunately not directly on IPsec, > but with the introduction of the SCHC Header which may be also needed for > IPsec. > > Laurent > > On Mon, Oct 30, 2023 at 9:19 PM Daniel Migault > wrote: > >> Sure, we will work to get completely aligned with SCHC and lead that >> document in both WG.I agree some aspects need to be clarified and will be >> clarified. >> >> Yours, >> Daniel >> >> On Mon, Oct 30, 2023 at 3:30 PM Ana Minaburo >> wrote: >> >>> Hello Daniel, >>> From my point of view you need to work more on your draft to be aligned >>> with SCHC. This work needs a better understanding of the SCHC header >>> compression. >>> And it will be required to be worked in parallel in both SCHC and >>> IPsecME WG. >>> >>> Ana >>> >>> >>> On Mon, Oct 30, 2023 at 12:10 PM Daniel Migault >>> wrote: >>> >>>> Just to let you know that we will have a call for adoption for >>>> diet-esp, that is IPsec/ESP compression with SCHC.I will be in Prague so we >>>> can also discuss this face to face. >>>> >>>> Yours, >>>> Daniel >>>> >>>> -- Forwarded message - >>>> From: Tero Kivinen >>>> Date: Sun, Oct 29, 2023 at 10:07 PM >>>> Subject: [IPsec] Agenda for IETF 118 >>>> To: >>>> >>>> >>>> IP Security Maintenance and Extensions (IPsecME) WG. >>>> >>>> IETF 118 - Thursday November 9th, 2023 13:00-14:30 CET >>>> https://meetings.conf.meetecho.com/ietf118/?group=ipsecme==1 >>>> >>>> Agenda >>>> >>>> - Note Well, technical difficulties and agenda bashing - >>>> Chairs (5 min) >>>> - Document Status - >>>> Chairs (5 min) >>>> - Adoption calls (5 min) >>>> - draft-liu-ipsecme-ikev2-mtu-dect >>>> - draft-mglt-ipsecme-dscp-np >>>> - draft-mglt-ipsecme-diet-esp >>>> - draft-mglt-ipsecme-ikev2-diet-esp-extension >>>> - draft-smyslov-ipsecme-ikev2-cookie-revised >>>> - Other items >>>> - Issues with DH with IKEv2 and rekeys (15 min) >>>> Paul Wouters >>>> - QR alt update (10 min) >>>> Valery Smyslov >>>> - Anti-replay sequence number subspaces (10 min) >>>> Pierre Pfister >>>> - Update of multiple sequence counters (10 min) >>>> Steffen Klassert >>>> - Beet mode (10 min) >>>> Antony Antony >>>> - Esp trailer adjustment (5 min) >>>> Wei Pan >>>> - Delete info (5 min) >>>> Paul Waters >>>> - RISAV update (5 min) >>>> Yangfei Guo >>>> - AOB + Open Mic (5 min) >>>> -- >>>> kivi...@iki.fi >>>> >>>> ___ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> >>>> -- >>>> Daniel Migault >>>> Ericsson >>>> >>> >> >> -- >> Daniel Migault >> Ericsson >> > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Agenda for IETF 118
Sure, we will work to get completely aligned with SCHC and lead that document in both WG.I agree some aspects need to be clarified and will be clarified. Yours, Daniel On Mon, Oct 30, 2023 at 3:30 PM Ana Minaburo wrote: > Hello Daniel, > From my point of view you need to work more on your draft to be aligned > with SCHC. This work needs a better understanding of the SCHC header > compression. > And it will be required to be worked in parallel in both SCHC and IPsecME > WG. > > Ana > > > On Mon, Oct 30, 2023 at 12:10 PM Daniel Migault > wrote: > >> Just to let you know that we will have a call for adoption for diet-esp, >> that is IPsec/ESP compression with SCHC.I will be in Prague so we can also >> discuss this face to face. >> >> Yours, >> Daniel >> >> -- Forwarded message - >> From: Tero Kivinen >> Date: Sun, Oct 29, 2023 at 10:07 PM >> Subject: [IPsec] Agenda for IETF 118 >> To: >> >> >> IP Security Maintenance and Extensions (IPsecME) WG. >> >> IETF 118 - Thursday November 9th, 2023 13:00-14:30 CET >> https://meetings.conf.meetecho.com/ietf118/?group=ipsecme==1 >> >> Agenda >> >> - Note Well, technical difficulties and agenda bashing - >> Chairs (5 min) >> - Document Status - >> Chairs (5 min) >> - Adoption calls (5 min) >> - draft-liu-ipsecme-ikev2-mtu-dect >> - draft-mglt-ipsecme-dscp-np >> - draft-mglt-ipsecme-diet-esp >> - draft-mglt-ipsecme-ikev2-diet-esp-extension >> - draft-smyslov-ipsecme-ikev2-cookie-revised >> - Other items >> - Issues with DH with IKEv2 and rekeys (15 min) >> Paul Wouters >> - QR alt update (10 min) >> Valery Smyslov >> - Anti-replay sequence number subspaces (10 min) >> Pierre Pfister >> - Update of multiple sequence counters (10 min) >> Steffen Klassert >> - Beet mode (10 min) >> Antony Antony >> - Esp trailer adjustment (5 min) >> Wei Pan >> - Delete info (5 min) >> Paul Waters >> - RISAV update (5 min) >> Yangfei Guo >> - AOB + Open Mic (5 min) >> -- >> kivi...@iki.fi >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> -- >> Daniel Migault >> Ericsson >> > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-07.txt
Hi, This version reflects the discussions on the mailing list. The discussion mostly lead to text clarification as the draft was already describing the outcome of the discussions. We believe draft is ready to be adopted. Yours, Daniel From: internet-dra...@ietf.org Sent: Friday, October 6, 2023 11:14 AM To: Congjie Zhang; Harold Liu; Daniel Migault; Renwang Liu Subject: New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-07.txt A new version of Internet-Draft draft-liu-ipsecme-ikev2-mtu-dect-07.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-liu-ipsecme-ikev2-mtu-dect Revision: 07 Title:IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension Date: 2023-10-06 Group:Individual Submission Pages:20 URL: https://www.ietf.org/archive/id/draft-liu-ipsecme-ikev2-mtu-dect-07.txt Status: https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/ HTMLized: https://datatracker.ietf.org/doc/html/draft-liu-ipsecme-ikev2-mtu-dect Diff: https://author-tools.ietf.org/iddiff?url2=draft-liu-ipsecme-ikev2-mtu-dect-07 Abstract: This document defines the IKEv2 Link Maximum Atomic Packet and Packet Too Big Extension to limit reassembly operations being performed by the egress security gateway. This extension enables an egress security gateway to notify its ingress counterpart that fragmentation is happening or that the received (and potentially reassembled) ESP packet is too big and thus cannot be decrypted. In both cases, the egress node provides Maximum Transmission Unit (MTU) information. Such information enables the ingress node to configure appropriately its Tunnel Maximum Transmission Unit - also designated as MTU or Tunnel MTU (TMTU) - to prevent fragmentation or too big packets to be transmitted. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-mglt-ipsecme-dscp-np-00.txt
Hi, Please find an updated version of the draft describing how initiators and responders can notify each other of the DSCP values considered for the agreed SA. We do not involve any more the TS but only involve an Notify payload. We rename the draft to reflect that change which explain why we have a 00 draft. We believe we have addressed all concerned raised so far. In our opinion the draft is ready to be adopted. Yours, Daniel From: internet-dra...@ietf.org Sent: Friday, October 6, 2023 11:04 AM To: Ulf Parkholm X; Harold Liu; Daniel Migault; Joel Halpern Subject: New Version Notification for draft-mglt-ipsecme-dscp-np-00.txt A new version of Internet-Draft draft-mglt-ipsecme-dscp-np-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-dscp-np Revision: 00 Title:Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification Date: 2023-10-06 Group:Individual Submission Pages:8 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-dscp-np-00.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-dscp-np/ HTMLized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-dscp-np Abstract: IPsec supports "classifier" mechanism to send traffic with specific Differentiated Services Field Codepoints (DSCP) over different tunnels. However, such classification is not explicitly notified to the other peer. This document specifies the DSCP Notification Payload, which, in a CREATE_CHILD_SA Exchange, explicitly mentions which DSCP code points will be tunneled in the newly created tunnel. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Hi Michael, As far as I understand it, yes, the two end sites are managed by the MNO. Yours, Daniel On Wed, Aug 9, 2023 at 9:27 AM Michael Richardson wrote: > > Tero Kivinen wrote: > > If we agree on the inner DSCP values, but map them differently that > > does not actually matter as long as we never bypass some DSCP values > > while mapping others, as every packet in the tunnel will have same > > outer DSCP value thus will receive same processing in the internet. > > Are the two ends/sites in the same administrative domain? > > > I think the easiest way of doing that is to add DSCP Status Notify > and > > use it like this: > > I agree. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > 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] draft-mglt-ipsecme-ts-dscp
Hi Tero, Thanks for the comments, this matches how we envisioned to update the draft, except that we envisioned the responder sends a N(DSCP) and that we also indicated the support of the N(DSCP). I think you recommend not to have these two notifications, which could work for us. Please see inline some other comments. Yours, Daniel On Tue, Aug 8, 2023 at 8:54 PM Tero Kivinen wrote: > Daniel Migault writes: > > I am coming back to one comment that has been made during the > > presentation that DSCP values do not necessarily be associated with > > a pair of SA. > > > > We want to organise tunnels where DSCP values are partitioned > > between a subset of SAs. More specifically suppose that we have g1 = > > (DSCP_a, DSCP_b), g2 = (DSCP_c) and g3 = (remaining DSCP) that are > > spread over 3 distinct pairs of SAs (SA1, SA2, and SA3). > > > > As long as peer A and peer B have agreed on 3 distinct SAs, and on a > > way to group the DSCP code point, the repartition could be left to > > each peer. For example, peer A may steer traffic g1 to SA1, g2, to > > SA2 and g3 to SA3, while peer B may steer g1 to SA3, g2 to SA2 and > > g3 to SA1. The tunnel may be split over a distinct pair of SAs. > > The reason we want to provide each of those groups separate SA is > because we have some information from somewhere that something in the > network will process the outer DSCP values differently, and that will > cause issues for the replay window. > > Note, that RFC4301 "4.4.1.2. Structure of an SPD Entry", already > specifies that you can either bypass DSCP value from inner to outer IP > header or you can map inner DSCP value using a map stored in the SPD > to DSCP values for outer IP header. > > In most cases you will have external knowledge that someone will > process your specific DSCP values differently on the outer IP header, > so you should most likely use that DSCP mapping to map all those > groups to specific outer DSCP values. > > So now the question really is which DSCP values you want to tell the > other peer? The outer IP header values are only ones that affect the > processing of the packet over the internet, so those would be more > logical ones. On the other hand that would require you to agree with > peers a same mapping of the inner to outer values. > > If we agree on the inner DSCP values, but map them differently that > does not actually matter as long as we never bypass some DSCP values > while mapping others, as every packet in the tunnel will have same > outer DSCP value thus will receive same processing in the internet. > > So that means we most likely should agree on the inner DSCP values, > and assume that both peers do have common understanding of those > values. > > If you want to keep the group so that it uses the same SA pair, then > if both peers already have common understanding of the DSCP groups, > this is not an really an issue, as we can simply wait for the > initiator to send first packet and see which DSCP value that has, and > after that the responder will know to which group this SA should be. > > Other option is to send a Notify payload while creating SA, where you > list the DSCP values you will be sending in this SA, so the responder > can use that information to populate the SAD. The RFC4301 "4.4.2.1. > Data Items in the SAD" describes that each SAD entry has a list of > DSCP values that are put to this SA. > > > If the SA used for those DSCP values is deleted then SA which do not > list DSCP values will be used (i.e., the fall back SA). If there is no > SA that does not list DSCP values, then the RFC4301 does not really > specify which SA is used, but I would assume it could use any SA. > I think we need to clarify this. 4301 is not crystal clear and I thought no SA would be selected, but I think that is correct any SA can be selected. > > > We can also argue that this does not prevent managing tunnels. > > Suppose peer A Deletes the tunnel associated to g1. It deletes SA1 > > and in the same way it deletes the SA peer B is steering traffic g3 > > to. Since Peer B knows that Peer A has chosen SA1 for g1, it can > > notice that g1 does not need to be considered so the SA3 has one > > unused SA and that g3 may use instead SA3. > > The question I have why are the gateways deleting the SAs at randomly? > Usually you simply rekey the SA, not just randomly delete some SA. > Things are much easier if implementations do smart things. > > So the answer to this question is "please peer A, do not delete the > SA, rekey it"... > I was thinking of moving the traffic to another gateway as an example of tunnel management. > > > As a result, this makes it
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
I am coming back to one comment that has been made during the presentation that DSCP values do not necessarily be associated with a pair of SA. We want to organise tunnels where DSCP values are partitioned between a subset of SAs. More specifically suppose that we have g1 = (DSCP_a, DSCP_b), g2 = (DSCP_c) and g3 = (remaining DSCP) that are spread over 3 distinct pairs of SAs (SA1, SA2, and SA3). As long as peer A and peer B have agreed on 3 distinct SAs, and on a way to group the DSCP code point, the repartition could be left to each peer. For example, peer A may steer traffic g1 to SA1, g2, to SA2 and g3 to SA3, while peer B may steer g1 to SA3, g2 to SA2 and g3 to SA1. The tunnel may be split over a distinct pair of SAs. We can also argue that this does not prevent managing tunnels. Suppose peer A Deletes the tunnel associated to g1. It deletes SA1 and in the same way it deletes the SA peer B is steering traffic g3 to. Since Peer B knows that Peer A has chosen SA1 for g1, it can notice that g1 does not need to be considered so the SA3 has one unused SA and that g3 may use instead SA3. As a result, this makes it possible to partition DSCP values into m categories over m distinct pairs of SAs. It could be convenient if we could create m pairs of SAs in one shot in which case we could also provide the DSCP partition and let the two peer to select their favourite SA. However, things look more complex when we are creating SAs one by one, and only once we have created the SAs, we could mention the DSCP partition into m partition as well as the m (or 2 m) SPIs being considered. It also seems that each peer will need to monitor which DSCP is associated with which unidirectional SA. I have the impression that associating the DSCP group to each SA seems an easier approach. We are losing that independence between SA and DSCP, but I do not see the real benefit of it. One drawback I could see is that by providing a partition of DSCP values, we may be able to force that DSCP value be partitioned, while currently we leave that responsibility to the establishment of policies. I am wondering if I am missing anything or if we envision other ways to manage DSCP values. Yours, Daniel On Thu, Jul 27, 2023 at 10:49 AM Daniel Migault wrote: > Thanks Tero, this is helpful and overall improves the design. Please see > inline additional comments/questions. We basically would like to know if > these DSCP selectors could be reasonably called "pseudo traffic selectors" > or if someone believes that will be confusing. Feel free to suggest other > alternatives. The other question we have is whether the Notify > payload should be generic to Pseudo TS or limited to DSCP. > > I will later address Scott comments on whether we need or not to bind the > DSCP value to a SA. > > Yours, > Daniel > > On Wed, Jul 26, 2023 at 11:20 PM Tero Kivinen wrote: > >> Daniel Migault writes: >> > I am under the impression that if one wants to ensure that the >> agreed DSCP >> > value takes the right SA we need to check that. As a result, I am >> inclined to >> > have in any case a MUST be checked. I am wondering if we are expecting >> this >> > check to take a significant overhead ? >> >> I do not think there should be any need to check that agreed on DSCP >> values takes right SA. >> >> As the issue is that packets get dropped because of the replay window >> checks, then it does not matter which SA they use as long as the >> packets do not get dropped. >> >> I see, so this definitively implies all DSCP values have the same policy. > Now that DSCP is not a traffic selector can we consider that one cannot > have different policies for different DSCP values ? Is pseudo traffic > selector an appropriate terminology ? I am happy to get a better > designation. > > >> The sender has incentive to send them in best possible SA to make sure >> they do not get dropped, but even that does not guarantee that someone >> in the network does not decide to process the packets differently by >> for example modifying the outer DSCP values in some way. >> >> > I do not see a major change between using TS and a Notify. In both >> > cases if the ts_dscp or the notify is not sent or not supported we >> > fall back to the old case. So I do not expect that ts_dscp updates >> > 4301 (maybe I am wrong). As a result, I am wondering what are the >> > advantages of using a notification as opposed to a TS ? >> >> There is big difference using traffic selectors and notify. First of >> all that traffic selector would need special handling and coding in >> the implementations to be understood at all. Old implementations would >> at best return traffic selector set which do not include that
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Hi everyone, Considering the various comments here is our understanding of the IKE PTB status. The IKE PTB, in our view, is largely motivated by enabling the egress interface to provide the EMTU_R to the ingress interface. This results from the discussion with Joe Touch who references the document in section 4.2.2.1 of draft-intarea-tunnels [1]. As there is a long history where tunnels have been established without this parameter, we may be able to live without that message, however we believe that it is better to have such a mechanism. Typically, with an IPsec tunnel, a packet that exceeds the EMTU_R (let’s say after reassembly), will not result in sending an ICMP PTB neither by the interface nor by the router. That packet will be discarded, and the ingress node will not be informed of it. In our mind the EMTU_R can result from a combination between a hardware configuration parameter, the egress interface and optionally the MTU of the egress router. We believe that the EMTU_R may change over time and that it should be provided when a packet exceeds that EMTU_R as opposed to being provided once for all during the IKE exchange. However, we agree that EMTU_R and MTU may be provided during the IKE exchange. So far, our position is that the IKE PTB should be specified. We also envisioned some additional advantages that the IKE PTB MAY provide. However, while these have been discussed, we want to make it clear that these other advantages are secondary. Firstly IKE PTB MAY be sent in conjunction of an ICMP PTB by the interface. The advantages of doing so are that ICMP is authenticated and clearly associated with the SA. More specifically, an ICMP PTB sent upon receiving an UDP/ESP packet does not carry the SPI. However, this advantage is only provided by the egress interface and so that mechanism cannot be used by any other node, and so cannot be used for PMTU discovery. Secondly, the IKE PTB MAY be sent together with the ICMP PTB sent by the router. We believe this improves the network latency and optimizes the use of the security gateway resources. In fact the ICMP PTB sent by the egress router is sent specifically to the sending source, and so one can expect the ICMP PTB being sent to every source. By sending the IKE PTB, the ICMP PTB would be sent by the ingress router. This prevents the large packet greater than the MTU to be encrypted and sent to the egress router for nothing. We believe this could be an interesting use case. Please let us know if you agree / disagree, so we can update and clarify the draft along these lines. We will also clarify the “too large to be decrypted”. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ On Sat, Aug 5, 2023 at 10:44 PM Daniel Migault wrote: > > > On Wed, Aug 2, 2023 at 11:28 AM Paul Wouters wrote: > >> On Tue, 1 Aug 2023, Daniel Migault wrote: >> >> [The quoting got mangled in Daniel's message] >> >> > If an incoming Encrypted packet is larger than the Link MTU >> > >> > >> > How can than be? You mean you received an ESP or ESPinUDP that after >> decrypting was too large for the >> > link you need to send the decrypted packet on? That seems really odd. >> > >> > I was trying to mention the very basic use of ICMP PTB here. There is >> no decryption at that point, that is if an IP packet IP/ESP or >> > IP/UDP/ESP is larger than the link MTU, an ICMP PTB will be sent. >> >> But before decryption, when using tunnel mode, you wouldn't know which >> interface to send the packet to, so you don't know yet if it is too big >> or not. So that makes me understand this use case even less. >> >> > an ICMP PTB is sent, otherwise the packet is accepted. If fragments >> are received, a reassembly operation happens and the packet may >> > be too large to be built or decrypted. >> > >> > What is this “too large to decrypt” scenario ? Can you give more >> details? >> > >> > The reassembled packet is larger than EMTU_R for example. >> >> EMTU_R you defined as "effective MTU to receive". As you received >> fragments that fit that mtu, why does it matter what the reassembled >> packet size is? It would only matter if you would (after successfull >> decryption), need to send the packet back over the same interface. >> >> We want to avoid fragmentation but fragmentation remains supported. > EMTU_R is sent as an information to the peer that the fragmented packet has > not been handled by the egress gateway. > > >> My problem is that between Daniel and Joel explanations, I still haven't >> managed to understand the actual problem, so I have a really hard time >> understanding the proposed fix and whether it really would solve >>
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, Aug 2, 2023 at 11:28 AM Paul Wouters wrote: > On Tue, 1 Aug 2023, Daniel Migault wrote: > > [The quoting got mangled in Daniel's message] > > > If an incoming Encrypted packet is larger than the Link MTU > > > > > > How can than be? You mean you received an ESP or ESPinUDP that after > decrypting was too large for the > > link you need to send the decrypted packet on? That seems really odd. > > > > I was trying to mention the very basic use of ICMP PTB here. There is no > decryption at that point, that is if an IP packet IP/ESP or > > IP/UDP/ESP is larger than the link MTU, an ICMP PTB will be sent. > > But before decryption, when using tunnel mode, you wouldn't know which > interface to send the packet to, so you don't know yet if it is too big > or not. So that makes me understand this use case even less. > > > an ICMP PTB is sent, otherwise the packet is accepted. If fragments are > received, a reassembly operation happens and the packet may > > be too large to be built or decrypted. > > > > What is this “too large to decrypt” scenario ? Can you give more details? > > > > The reassembled packet is larger than EMTU_R for example. > > EMTU_R you defined as "effective MTU to receive". As you received > fragments that fit that mtu, why does it matter what the reassembled > packet size is? It would only matter if you would (after successfull > decryption), need to send the packet back over the same interface. > > We want to avoid fragmentation but fragmentation remains supported. EMTU_R is sent as an information to the peer that the fragmented packet has not been handled by the egress gateway. > My problem is that between Daniel and Joel explanations, I still haven't > managed to understand the actual problem, so I have a really hard time > understanding the proposed fix and whether it really would solve > something. > > I think this is normal as these are two unrelated use cases/concerns. Joel was describing DSCP being used as a pseudo traffic selector. https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ > As Joe Touch wrote in January: > > The abstract clearly states a goal that is not achievable (of > avoiding > reassembly). The best way to avoid the impact of mid-tunnel > fragmentation > is to use IPv4 as a tunnel header the way that IPv6 would be - with > DF=1. However, even so, the egress always needs to handle > reasssembly > as long as there is even source fragmentation. > > I appreciate what you WANT to do - but again, it is not possible. > You > have two behaviors - either use inner fragmentation (which won’t > work > for transit traffic where IPv4 DF=1 or any IPv6) or reduce the > tunnel MTU. > > But the tunnel MTU is defined by EMTU_R of the tunnel egress, not > EMTU_S > of the tunnel ingress. If you reduce the tunnel MTU, you’re just > going > to end up black-holing packets arriving at the tunnel ingress. > > Two important points: the tunnel ingress is NOT the one that should > ever send PTB back; that’s the job of the router where/if that > tunnel > ingress resides; second, you cannot claim to get around an ICMP > black > hole situation by creating a new ICMP black hole situation. > > > I am happy to understand why you think we do avoid reassembly. At least on our side it solves our issue. > Paul > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Thu, Aug 3, 2023 at 9:12 AM Michael Richardson wrote: > > Paul Wouters wrote: > >> > Or use IPTFS and set your own max packet size sufficiently low? > >> > >> I think that this is the killer app for IPTFS. > >> > > > But of course this means either IPTFS should be able to auto-tune > this, > > or else we end up with hardcoded configs that might stop working or > > cause future problems. > > I think that the ESPping mechanism is the right way to do "PLPMTUD" for > IPTFS. > (for the outer MTU) > I also think so. > > >> > I'm not convinced doing this between IPsec peers will solve any > real > >> > use cases. > >> > >> I am also skeptical, but I don't object to the work getting > >> standardized. > >> > >> In particular, for networks where there are MTU constraints on the > far > >> side of the far gateway, telling the sending gateway about the MTU > has > >> a far higher chance of working than anything else. The sending > >> gateway probably can send PTB ICMPs with better results. > > > There would need to be dynamic updating, kernel <-> userland > > communications, etc. Just hardcoding this in an ikev2 configuration > > would be pretty bad. > > yeah, I don't know exactly how to do the userland communication. > How specific does it need to be is my question? How express that. > Looking at mtu-dect, I'm unclear how the LMAP and and PTB describe the flow > which has the MTU concern. It's mostly clear when it appears along with > TSx > that it applies to that traffic, but not for the other notifications. > > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > 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] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, Aug 2, 2023 at 1:02 AM Christian Hopps wrote: > > "Panwei (William)" writes: > > > Hi Daniel, > > > > > > > > Thanks for your clarification, I think I may have better > > understanding of your problem statement. I try to give an example > > below, please correct me if I’m wrong. > > > > First, let’s assume the encryption/decryption capability of ingress > > node is 15000 bytes and the capability of egress node is 5000 bytes. > > And, in one case, the original (inner) packet which needs to be > > encrypted by the ingress node is 9000 bytes. > > > > The ingress node encrypts this packet and adds the IPsec > > encapsulation, and this IPsec-processed packet is also larger than > > the Link MTU. The ingress node fragments this IPsec-processed packet > > and sends all the fragments to the egress node. > > This should not happen. The ingress node should first fragment the inner > IP packet so that it fits in the tunnel (i.e., so that the ESP packets it > creates do not violate it's own MTU). > It is correct that inner packets are not expected to exceed the tunnel MTU. But in your case if the tunnel MTU is 15000 and teh packet is 9000 bytes, your understanding seems correct. According to draft-ietf-intarea-tunnels the ingress node compares the inner packet with tunMAP - that is the largest packet that does not result in fragmentation. If the packet exceeds such size, the ingress gateway encapsulates the packet and fragments the big packet. While the numbers are not realistic, if the tunnel MTU is 15000 and you send a 9000 byte packet, the ingress gateway will send 500 bytes fragments. These fragments will be reassembled by the egress before performing the decryption. It needs to be able to handle a 9000 byte packet. > > The egress node reassembles the packet and realizes the encrypted > > packet exceeds its decryption capability, so it will drop the packet > > and notify the ingress node. > > Yes, that is correct. > > I don’t know whether this case is a real problem. And, I also don’t > > know whether the ICMP PTB can solve the problem. If not, then I agree > > the IKE PTB defined by this draft is a way to forward. > > I was thinking this "size exceeds decryption capability" is some sort of > miscommunication. The draft talks about "packet too big and can't be > decrypted", but is it really trying to say "the outer ESP packet didn't > arrive b/c it was TOO BIG."? > Otherwise is the text actually talking about a real limitation of some > IPsec implementations -- that they can only decrypt up to a certain number > of bytes per packet? It seems outrageous. :) > > I see. In my mind it cannot be decrypted as I imagine ipsec does not have the full packet - basically it happens before the decapsulation. But I see your point. I will clarify this. > Thanks, > Chris. > > > > Besides that, I found many acronyms are used in this draft. I think > > simplifying them may be better for understanding. > > > > For example, LMTU (Link MTU) and LMAP (Link Maximum Atomic Packet) > > are both used, but I feel they are the same thing. > > > > TLP (Tunnel Link Packet) and LTP (no definition) are both used, and I > > think LTP is misspelled. In some cases, “IPsec encapsulated TTP” is > > used, and I think it also means TLP. > > > > > > > > Regards & Thanks! > > > > Wei Pan (潘伟) > > > > > > > > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Daniel > > Migault > > Sent: Wednesday, August 2, 2023 12:56 AM > > To: Ben Schwartz > > Cc: Harold Liu ; > > ipsec@ietf.org > > Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > > > > > > > Hi Ben, > > > > Just trying to position our understanding of the position between the > ICMP PTB and the IKE PTB. > > > > If an incoming Encrypted packet is larger than the Link MTU, an ICMP PTB > is sent, otherwise the packet is accepted. If fragments are received, a > reassembly operation happens and the packet may be too large to be built or > decrypted. I am unaware of any ICMP signaling between the gateway that > could carry this information. As far as I understand, ICMP PTB is not > issued for a reassembled packet as long as each of the fragments are below > the MTU. This is the reason we send the EMTU_R which designates the maximum > size the egress gateway can handle. > > > > EMTU_R could be a configuration parameter that would not change, but > that value also considers the MTU of the router part which can be changed. > > > > As soon as it passes the interfac
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, Aug 2, 2023 at 9:17 PM Michael Richardson wrote: > > Paul Wouters wrote: > >> Christian Hopps wrote: >> The ingress node > >> encrypts this packet and adds the IPsec >> encapsulation, and this > >> IPsec-processed packet is also larger than the >> Link MTU. The > >> ingress node fragments this IPsec-processed packet and >> sends all > >> the fragments to the egress node. > >> > >> > This should not happen. The ingress node should first fragment > the > > >> inner IP packet so that it fits in the tunnel (i.e., so that the > ESP > > >> packets it creates do not violate it's own MTU). > >> > >> You can't do that if DF=1, or IPv6. You can form big ESP packets > and > >> then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is > >> good, until there is a firewall that cant cope with fragments. > > > Why does any of this even matter? The applications should use > PLPMTUD / > > DPLPMTUD ? > > 1) For TCP things. We also have RFC9268 now. > > 2) how can we get it turned on by default? I tried to make this case to >Linux distros and kernel people, but there is a lack of evidence that >it is safe, and the people who might have the evidence (at scale) >don't want to do it. > > 3) the gateways really have no idea if PLPMTUD is being done, and sometimes >it's better to just make things work. > > > Sprinkling bits to try to communicate with hops in between hasn't > > worked for decades. > > Agreed. PMTUD is a fail. > > > Or use IPTFS and set your own max packet size sufficiently low? > > I think that this is the killer app for IPTFS. > > > I'm not convinced doing this between IPsec peers will solve any real > > use cases. > > I am also skeptical, but I don't object to the work getting standardized. > > In particular, for networks where there are MTU constraints on the far side > of the far gateway, telling the sending gateway about the MTU has a far > higher > chance of working than anything else. The sending gateway probably can > send > PTB ICMPs with better results. > Just note that IKE PTB is really not the core of the draft and the LMAP is the main notification, IKE PTB is mentioned for completeness. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > 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] -ikev2-mtu-dect: IKEv2 PTB Notification
On Tue, Aug 1, 2023 at 10:18 PM Christian Hopps wrote: > Hi, > > FWIW, Here's what I was saying at the mic during the ipsec meeting @117. > It may have relevance to the discussion about EMTU... > > You own the tunnel endpoints since you're configuring security tunnels on > them. Normal PMTU will work fine if, for some reason, you need your ingress > to discover the egress endpoint's nexthop MTU (red-side link) dynamically. > This is b/c your not going to configure your own tunnel endpoints to drop > ICMP too big packets and break it yourself. So, you don't need any new > mechanism to discover your own downstream red side link MTUs. > I assume you mean PMTU between the ingress and egress node. We could use the normal PMTU mechanisms with ICMP but that is not always so easy and the information may not necessarily apply to IPsec traffic. Things that may make PMTU not that easy are router may not respond with ICMP PTB, ICMP PTB may be dropped by the network or firewall policies - one thing we need to consider is that the network between the two gateways is not managed by the same entity as the one operating the gateways. ). We were not expecting IKE PTB to take part of a PMTU process, but the IKE PTB is expected to be sent when the packet received is greater the EMTU_R (which is outside the scope of ICMP and a specific action performed by the egress security gateway) that is when fragmentation occurs - there are no mechanism that provide this data. It could be also used when an ESP packet is greater than the LMTU. In that latter case ICMP PTB and IKE PTB may play a similar role except that IKE PTB is authenticated and indicates the concerned SA. A typical ICMP PTB will not be able to indicate the SA for UDP encapsulated traffic. > Also, I'm pretty sure that most transit routers are configured to never > fragment forwarded packets (it's a DDOS attack vector), so I don't think > your going to be seeing the outer ESP IP packet be fragmented either. This > functionality is so unpopular it was completely eliminated from IPv6, so it > for sure will never happen if your outer encap is IPv6. > > We do have mid tunnel fragmentation (with IPv4 of course). DF=0 is also preferred over dropping packets which results in a blackholing situation. > Thanks, > Chris. > > Daniel Migault writes: > > > Hi Ben, > > > > Just trying to position our understanding of the position between the > ICMP PTB and the IKE PTB. > > > > If an incoming Encrypted packet is larger than the Link MTU, an ICMP PTB > is sent, otherwise the packet is accepted. If fragments are received, a > reassembly operation happens and the packet may be too large to be built or > decrypted. I am unaware of any ICMP signaling between the gateway that > could carry this information. As far as I understand, ICMP PTB is not > issued for a reassembled packet as long as each of the fragments are below > the MTU. This is the reason we send the EMTU_R which designates the maximum > size the egress gateway can handle. > > > > EMTU_R could be a configuration parameter that would not change, but > that value also considers the MTU of the router part which can be changed. > > > > As soon as it passes the interface, as I understand it, an ICMP PTB will > be sent to the Source and not the gateway. As I understand it, EMTU_R > defines the maximum payload the Link network is able to handle. In our > case, the payload is the encrypted ESP packet that may have been > reassembled. The packet is passed to the decryption. Once decrypted, the > clear text packet is passed to the router of the node. The router may send > an ICMP PTB, which will be sent to the Source or treat that packet. I see > EMTU_R as reflecting the node of the router with Tunnel MTU = EMTU_R - ESP > overhead > > > > Considering a ping encapsulated in esp - we may discover the MTU as well > as the EMTU_R by fragmenting unless we meet EMTU_R. > > > > Note also that since we want to avoid fragmentation having a discovery > mechanism that relies on fragmentation may not be the best idea. > > > > Yours, > > Daniel > > > > > > On Mon, Jul 31, 2023 at 1:22 PM Daniel Migault > > wrote: > > > > An encapsulated ICMP ECHO would get a response from the router > > (not the interface) of the security gateway. I have not read > > carefully draft-colitti-ipsecme-esp-ping but this is potentially > > what we could use to discover that path upon which we could set > > DF=1. That said, if MTU changes, we need to receive a > > notification. > > I tend to think that extending colitti-ipsecme-esp-ping to other > > ICMP plus defining PLMTU could replace our IKE PTB. > > > > > &g
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Hi Paul, Please see my response in line. Yours, Daniel On Tue, Aug 1, 2023 at 2:15 PM Paul Wouters wrote: > On Aug 1, 2023, at 12:56, Daniel Migault wrote: > > > > > Hi Ben, > > Just trying to position our understanding of the position between the ICMP > PTB and the IKE PTB. > > If an incoming Encrypted packet is larger than the Link MTU > > > How can than be? You mean you received an ESP or ESPinUDP that after > decrypting was too large for the > link you need to send the decrypted packet on? That seems really odd. > I was trying to mention the very basic use of ICMP PTB here. There is no decryption at that point, that is if an IP packet IP/ESP or IP/UDP/ESP is larger than the link MTU, an ICMP PTB will be sent. > > an ICMP PTB is sent, otherwise the packet is accepted. If fragments are > received, a reassembly operation happens and the packet may be too large to > be built or decrypted. > > > What is this “too large to decrypt” scenario ? Can you give more details? > The reassembled packet is larger than EMTU_R for example. > > Paul > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Hi Ben, Just trying to position our understanding of the position between the ICMP PTB and the IKE PTB. If an incoming Encrypted packet is larger than the Link MTU, an ICMP PTB is sent, otherwise the packet is accepted. If fragments are received, a reassembly operation happens and the packet may be too large to be built or decrypted. I am unaware of any ICMP signaling between the gateway that could carry this information. As far as I understand, ICMP PTB is not issued for a reassembled packet as long as each of the fragments are below the MTU. This is the reason we send the EMTU_R which designates the maximum size the egress gateway can handle. EMTU_R could be a configuration parameter that would not change, but that value also considers the MTU of the router part which can be changed. As soon as it passes the interface, as I understand it, an ICMP PTB will be sent to the Source and not the gateway. As I understand it, EMTU_R defines the maximum payload the Link network is able to handle. In our case, the payload is the encrypted ESP packet that may have been reassembled. The packet is passed to the decryption. Once decrypted, the clear text packet is passed to the router of the node. The router may send an ICMP PTB, which will be sent to the Source or treat that packet. I see EMTU_R as reflecting the node of the router with Tunnel MTU = EMTU_R - ESP overhead Considering a ping encapsulated in esp - we may discover the MTU as well as the EMTU_R by fragmenting unless we meet EMTU_R. Note also that since we want to avoid fragmentation having a discovery mechanism that relies on fragmentation may not be the best idea. Yours, Daniel On Mon, Jul 31, 2023 at 1:22 PM Daniel Migault wrote: > An encapsulated ICMP ECHO would get a response from the router (not the > interface) of the security gateway. I have not read carefully > draft-colitti-ipsecme-esp-ping but this is potentially what we could use > to discover that path upon which we could set DF=1. That said, if MTU > changes, we need to receive a notification. > I tend to think that extending colitti-ipsecme-esp-ping to other ICMP > plus defining PLMTU could replace our IKE PTB. > > > On Mon, Jul 31, 2023 at 12:57 PM Ben Schwartz wrote: > >> It seems to me that the statement "This packet is too big for me to >> decrypt" is quite different from "This packet arrived fragmented". The >> former can generally be negotiated in the handshake, whereas the latter is >> a dynamic behavior of the underlying path. >> >> Monitoring the Path MTU is important, even when the path traverses an >> ICMP blackhole. So while I don't see the value of the PTB extension, I can >> understand the rationale for the LMAP extension. However, I would like to >> see a bit more description of the whole system. How do I send path probes >> to elicit these responses? Can I use ICMP ECHO inside the tunnel, or do we >> need draft-colitti-ipsecme-esp-ping? If we have path probes, why not just >> set DF=1 on the outer header for PMTUD? >> >> --Ben Schwartz >> -- >> *From:* Daniel Migault >> *Sent:* Monday, July 31, 2023 12:10 PM >> *To:* Ben Schwartz >> *Cc:* Harold Liu ; >> ipsec@ietf.org >> *Subject:* Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification >> >> Hi Ben, Please see my comments. On Mon, Jul 31, 2023 at 10: 47 AM Ben >> Schwartz wrote: Hi Harold, It sounds like you're >> describing a different problem. Daniel mentioned a concern about cases in >> which "the encrypted >> Hi Ben, >> Please see my comments. >> On Mon, Jul 31, 2023 at 10:47 AM Ben Schwartz wrote: >> >> Hi Harold, >> >> It sounds like you're describing a different problem. Daniel mentioned a >> concern about cases in which "the encrypted packet is too big and so cannot >> be decrypted". >> >> We see the MTU indicating the size the packet the egress interface is >> able to handle which includes the ability to reassemble and decrypt the >> packet. In that sense, I see sending the EMTU_R as very similar to an ICMP >> PTB except. I am wondering if you see any reasons for these issues to be >> considered differently and how you think such distinction could help. >> >> That's quite different from an MTU limit on the forwarding path, which >> can be dealt with using ordinary IP fragmentation and PMTUD. >> >> Fragmentation works, but costs too much resources and this draft is >> aiming at reducing such operations. Our concern is with IPv4, where DF=1 >> leads to a blackholing situation. PMTUD is extremely difficult as ICMP >> messages are not received by the ingress gateway. >> PLMTUD I-D.spiriyath-ipsecme-dynamic-
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
An encapsulated ICMP ECHO would get a response from the router (not the interface) of the security gateway. I have not read carefully draft-colitti-ipsecme-esp-ping but this is potentially what we could use to discover that path upon which we could set DF=1. That said, if MTU changes, we need to receive a notification. I tend to think that extending colitti-ipsecme-esp-ping to other ICMP plus defining PLMTU could replace our IKE PTB. On Mon, Jul 31, 2023 at 12:57 PM Ben Schwartz wrote: > It seems to me that the statement "This packet is too big for me to > decrypt" is quite different from "This packet arrived fragmented". The > former can generally be negotiated in the handshake, whereas the latter is > a dynamic behavior of the underlying path. > > Monitoring the Path MTU is important, even when the path traverses an ICMP > blackhole. So while I don't see the value of the PTB extension, I can > understand the rationale for the LMAP extension. However, I would like to > see a bit more description of the whole system. How do I send path probes > to elicit these responses? Can I use ICMP ECHO inside the tunnel, or do we > need draft-colitti-ipsecme-esp-ping? If we have path probes, why not just > set DF=1 on the outer header for PMTUD? > > --Ben Schwartz > -- > *From:* Daniel Migault > *Sent:* Monday, July 31, 2023 12:10 PM > *To:* Ben Schwartz > *Cc:* Harold Liu ; > ipsec@ietf.org > *Subject:* Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > Hi Ben, Please see my comments. On Mon, Jul 31, 2023 at 10: 47 AM Ben > Schwartz wrote: Hi Harold, It sounds like you're > describing a different problem. Daniel mentioned a concern about cases in > which "the encrypted > Hi Ben, > Please see my comments. > On Mon, Jul 31, 2023 at 10:47 AM Ben Schwartz wrote: > > Hi Harold, > > It sounds like you're describing a different problem. Daniel mentioned a > concern about cases in which "the encrypted packet is too big and so cannot > be decrypted". > > We see the MTU indicating the size the packet the egress interface is able > to handle which includes the ability to reassemble and decrypt the packet. > In that sense, I see sending the EMTU_R as very similar to an ICMP PTB > except. I am wondering if you see any reasons for these issues to be > considered differently and how you think such distinction could help. > > That's quite different from an MTU limit on the forwarding path, which can > be dealt with using ordinary IP fragmentation and PMTUD. > > Fragmentation works, but costs too much resources and this draft is aiming > at reducing such operations. Our concern is with IPv4, where DF=1 leads to > a blackholing situation. PMTUD is extremely difficult as ICMP messages are > not received by the ingress gateway. > PLMTUD I-D.spiriyath-ipsecme-dynamic-ipsec-pmtu for ESP is another path, > but it would take a lot of effort. > > Yours, > Daniel > > > --Ben SchwartzI-D.spiriyath-ipsecme-dynamic-ipsec-pmtu > -- > *From:* Harold Liu > *Sent:* Sunday, July 30, 2023 9:28 PM > *To:* Ben Schwartz ; Daniel Migault > *Cc:* ipsec@ietf.org > *Subject:* RE: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > Ben, thanks for your comment. Yes at the beginning we thought what you > thought, we consider the solution as “Negotiate it up front (in IKEv2)”, > however the challenge here is the MTU of the router on the forwarding path > can be changed at any > > Ben, thanks for your comment. > > > > Yes at the beginning we thought what you thought, we consider the solution > as “Negotiate it up front (in IKEv2)”, however the challenge here is the > MTU of the router on the forwarding path can be changed at any time (for > example, the router changes the configuration for some reason, or changes > the forwarding path for some reason). > > > > If the MTU of any forwarding node on the forwarding path changes (even as > to the whole forwarding path changes), a pre-negotiated MTU is probably not > applicable. Therefore, we defined the solution is to discover MTU in-band > via error responses. > > > > Brs > > > > *From:* IPsec *On Behalf Of *Ben Schwartz > *Sent:* Saturday, July 29, 2023 8:01 AM > *To:* Daniel Migault > *Cc:* ipsec@ietf.org > *Subject:* Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > > > +mailing list (oops) > > > > I think I understand the difficulty here. In IPv6, a "maximum reassembled > ESP size" can be modeled as a next-hop MTU on the plaintext, but in IPv4 an > enormous ESP could be decrypted and fragmented forward over a next hop with > a reasonable MTU. > >
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Hi Ben, Please see my comments. On Mon, Jul 31, 2023 at 10:47 AM Ben Schwartz wrote: > Hi Harold, > > It sounds like you're describing a different problem. Daniel mentioned a > concern about cases in which "the encrypted packet is too big and so cannot > be decrypted". > We see the MTU indicating the size the packet the egress interface is able to handle which includes the ability to reassemble and decrypt the packet. In that sense, I see sending the EMTU_R as very similar to an ICMP PTB except. I am wondering if you see any reasons for these issues to be considered differently and how you think such distinction could help. > That's quite different from an MTU limit on the forwarding path, which can > be dealt with using ordinary IP fragmentation and PMTUD. > Fragmentation works, but costs too much resources and this draft is aiming at reducing such operations. Our concern is with IPv4, where DF=1 leads to a blackholing situation. PMTUD is extremely difficult as ICMP messages are not received by the ingress gateway. PLMTUD I-D.spiriyath-ipsecme-dynamic-ipsec-pmtu for ESP is another path, but it would take a lot of effort. Yours, Daniel > --Ben SchwartzI-D.spiriyath-ipsecme-dynamic-ipsec-pmtu > -- > *From:* Harold Liu > *Sent:* Sunday, July 30, 2023 9:28 PM > *To:* Ben Schwartz ; Daniel Migault > *Cc:* ipsec@ietf.org > *Subject:* RE: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > Ben, thanks for your comment. Yes at the beginning we thought what you > thought, we consider the solution as “Negotiate it up front (in IKEv2)”, > however the challenge here is the MTU of the router on the forwarding path > can be changed at any > > Ben, thanks for your comment. > > > > Yes at the beginning we thought what you thought, we consider the solution > as “Negotiate it up front (in IKEv2)”, however the challenge here is the > MTU of the router on the forwarding path can be changed at any time (for > example, the router changes the configuration for some reason, or changes > the forwarding path for some reason). > > > > If the MTU of any forwarding node on the forwarding path changes (even as > to the whole forwarding path changes), a pre-negotiated MTU is probably not > applicable. Therefore, we defined the solution is to discover MTU in-band > via error responses. > > > > Brs > > > > *From:* IPsec *On Behalf Of *Ben Schwartz > *Sent:* Saturday, July 29, 2023 8:01 AM > *To:* Daniel Migault > *Cc:* ipsec@ietf.org > *Subject:* Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > > > +mailing list (oops) > > > > I think I understand the difficulty here. In IPv6, a "maximum reassembled > ESP size" can be modeled as a next-hop MTU on the plaintext, but in IPv4 an > enormous ESP could be decrypted and fragmented forward over a next hop with > a reasonable MTU. > > > > If this kind of ESP size limit is allowed, I think the best architecture > would be to negotiate it up front (in IKEv2) since it is a static property > of the endpoints, rather than discovering it in-band via error responses. > > > > --Ben Schwartz > -- > > *From:* Daniel Migault > *Sent:* Friday, July 28, 2023 10:47 AM > *To:* Ben Schwartz > *Subject:* Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > > > I see the next link as being the network behind the egress security > gateway in which case the paquet would be the clear text packet. In that > case maybe we could expect a ICMP PTB being sent to the source. The > scenario we have is the packet > > I see the next link as being the network behind the egress security > gateway in which case the paquet would be the clear text packet. In that > case maybe we could expect a ICMP PTB being sent to the source. > > The scenario we have is the packet being so big that decryption cannot be > performed - for example once reassembled. The egress security gateway has > an ESP packet that it cannot process. The normal way would be to send an > ICMP PTB but that ICMP PTB does not contain sufficient information for the > egress to address the issue. The IKE message could be seen as duplicating > the ICMP PTB with additional guarantees. > > > > Yours, > Daniel > > > > On Fri, Jul 28, 2023 at 1:33 AM Ben Schwartz wrote: > > I don't understand what it would mean for an ESP packet to be "too big to > be decrypted". Do you mean that the decrypted payload is too big to > deliver on the next link? > > > > --Ben Schwartz > -- > > *From:* IPsec on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Sent:* Thursday, July 27, 2023 9:32 PM &
[IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
In yesterday's presentation of the -ikev2-mtu-dect draft, I was asked why do we have such a notification instead of using a standard ICMP PTB message encapsulated in ESP. I believe the confusion comes from me saying that the PTB message is sent AFTER the packet has been decrypted. This is not the case as the PTB is sent BECAUSE the encrypted packet is too big and so cannot be decrypted. In other words the packet that is too big is the ESP packet. If the packet is too big and cannot be decrypted a Packet Too Big Notification (PTB) that specifies the Link MTU (LMTU) of the router component of the egress node (on network N) as well as the effective MTU to receive (EMTU_R). Both are configuration parameters. An ICMP PTB message may also be sent by the egress node. Note that this ICMP may not contain even the SPI, and so is likely to not carry sufficient information to the ingress node, so any action be taken. Typically the ICMP message only carries the first 8 bytes start from IP header of the original packets. This is not sufficient when encapsulated as the 8 bytes will not contain the SPI and the egress gateway will not be able to identify the concerned SA and so the concerned flow. Yours, Daniel -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Thanks Tero, this is helpful and overall improves the design. Please see inline additional comments/questions. We basically would like to know if these DSCP selectors could be reasonably called "pseudo traffic selectors" or if someone believes that will be confusing. Feel free to suggest other alternatives. The other question we have is whether the Notify payload should be generic to Pseudo TS or limited to DSCP. I will later address Scott comments on whether we need or not to bind the DSCP value to a SA. Yours, Daniel On Wed, Jul 26, 2023 at 11:20 PM Tero Kivinen wrote: > Daniel Migault writes: > > I am under the impression that if one wants to ensure that the > agreed DSCP > > value takes the right SA we need to check that. As a result, I am > inclined to > > have in any case a MUST be checked. I am wondering if we are expecting > this > > check to take a significant overhead ? > > I do not think there should be any need to check that agreed on DSCP > values takes right SA. > > As the issue is that packets get dropped because of the replay window > checks, then it does not matter which SA they use as long as the > packets do not get dropped. > > I see, so this definitively implies all DSCP values have the same policy. Now that DSCP is not a traffic selector can we consider that one cannot have different policies for different DSCP values ? Is pseudo traffic selector an appropriate terminology ? I am happy to get a better designation. > The sender has incentive to send them in best possible SA to make sure > they do not get dropped, but even that does not guarantee that someone > in the network does not decide to process the packets differently by > for example modifying the outer DSCP values in some way. > > > I do not see a major change between using TS and a Notify. In both > > cases if the ts_dscp or the notify is not sent or not supported we > > fall back to the old case. So I do not expect that ts_dscp updates > > 4301 (maybe I am wrong). As a result, I am wondering what are the > > advantages of using a notification as opposed to a TS ? > > There is big difference using traffic selectors and notify. First of > all that traffic selector would need special handling and coding in > the implementations to be understood at all. Old implementations would > at best return traffic selector set which do not include that new > traffic selector. On the other hand implementations might not be that > well written to handle unexpected traffic selectors. This was fine > with labeled ipsec as there it is assumed that both ends know that > both ends will support new traffic selectors. I would not be > suprised to find out that some implementations would NOT do that > narrowing properly when presented new traffic selector type, and > instead would return some fatal error. > > I see. That makes sense. > All current implemetations of the IKEv2 already knows that they need > ignore all unknown status notifications thus old implementations > getting DSCP notify would simply ignre it and the SA would be created > fine. > > > I do not see any and I am wondering if there are other reasons than > > that DSCP is not commonly used for access control. I have the > > impression this will be implemented the same way. In any case, if > > that is the reason I am wondering if we should restrict the draft to > > DSCP or consider that in the future additional parameters can be > > added or do we want to limiit it to DSCP ? > > DSCP is not access control it is giving hints to the router what type > of traffic is going through and what kind of QoS processing that type > of traffic might need. > I agree. My question was whether we believe it is better to define a PSEUDO_TRAFFIC_SELECTOR Notify Payload with a type set to DSCP versus a DSCP Notify Payload. In the first case we just get prepared if in 10 years there is a sudden need for an additional pseudo traffic selector. Yours, Daniel > -- > kivi...@iki.fi > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-mglt-ipsecme-ts-dscp-03.txt
Hi, Please find a new version of the draft. The draft considers some comments provided by Scott and Valery but has not considered comments received today. We expect to discuss the use of notify during the meeting and will update the draft accordingly. Yours, Daniel From: internet-dra...@ietf.org Sent: Wednesday, July 26, 2023 3:41 PM To: Ulf Parkholm X; Harold Liu; Daniel Migault; Joel Halpern Subject: New Version Notification for draft-mglt-ipsecme-ts-dscp-03.txt A new version of I-D, draft-mglt-ipsecme-ts-dscp-03.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-ts-dscp Revision: 03 Title: Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) Document date: 2023-07-26 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-ts-dscp-03.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ts-dscp Diff: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-ts-dscp-03 Abstract: Agreeing on SA with specific Differentiated Services Field Codepoints (DSCP) is not possible today as traffic selector does not consider DSCP. This document enables to further specify DSCP the current traffic selectors with a new Traffic Selector Type. The Traffic Selector Type can only be used in tunnel mode. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Thanks for the comments. I am under the impression that if one wants to ensure that the agreed DSCP value takes the right SA we need to check that. As a result, I am inclined to have in any case a MUST be checked. I am wondering if we are expecting this check to take a significant overhead ? I do not see a major change between using TS and a Notify. In both cases if the ts_dscp or the notify is not sent or not supported we fall back to the old case. So I do not expect that ts_dscp updates 4301 (maybe I am wrong). As a result, I am wondering what are the advantages of using a notification as opposed to a TS ? I do not see any and I am wondering if there are other reasons than that DSCP is not commonly used for access control. I have the impression this will be implemented the same way. In any case, if that is the reason I am wondering if we should restrict the draft to DSCP or consider that in the future additional parameters can be added or do we want to limiit it to DSCP ? Yours, Daniel On Wed, Jul 26, 2023 at 1:40 PM Tero Kivinen wrote: > Daniel Migault writes: > > Let me know if that text addresses your concern or if you prefer a > different > > wording. I believe I should add some more specific references to 4301. > > Note, that RFC4301 already describes how to handle DSCP, and your > draft would actually change mandatory features of RFC4301: > > In section 4.1 Definition and Scope of RFC4301 says: > >If different classes of traffic (distinguished by Differentiated >Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on >the same SA, and if the receiver is employing the optional >anti-replay feature available in both AH and ESP, this could result >in inappropriate discarding of lower priority packets due to the >windowing mechanism used by this feature. Therefore, a sender >SHOULD put traffic of different classes, but with the same selector >values, on different SAs to support Quality of Service (QoS) >appropriately. To permit this, the IPsec implementation MUST permit >establishment and maintenance of multiple SAs between a given >sender and receiver, with the same selectors. Distribution of >traffic among these parallel SAs to support QoS is locally >determined by the sender and is not negotiated by IKE. The receiver >MUST process the packets from the different SAs without prejudice. >These requirements apply to both transport and tunnel mode SAs. In >the case of tunnel mode SAs, the DSCP values in question appear in >the inner IP header. In transport mode, the DSCP value might change >en route, but this should not cause problems with respect to IPsec >processing since the value is not employed for SA selection and >MUST NOT be checked as part of SA/packet validation. However, if >significant re-ordering of packets occurs in an SA, e.g., as a >result of changes to DSCP values en route, this may trigger packet >discarding by a receiver due to application of the anti-replay >mechanism. > > I.e., it already says senders SHOULD use different SAs, and MUST > permit SAs with same selectors, and MUST process from each SA in same > way. > > > In section 4.4.1.2 Structure of an SPD Entry of RFC4301: > > - Bypass DSCP (T/F) or map to unprotected DSCP values > (array) if needed to restrict bypass of DSCP values > -- applicable to tunnel mode SAs > > I.e., SPD has option to specify whether DSCP is copied from inner to > outer or whether it is mapped using mapping array. > > In section 4.4.2.1 Data Items in the SAD of RFC4301: > > o DSCP values -- the set of DSCP values allowed for packets > carried over this SA. If no values are specified, no > DSCP-specific filtering is applied. If one or more values are > specified, these are used to select one SA among several that > match the traffic selectors for an outbound packet. Note that > these values are NOT checked against inbound traffic arriving on > the SA. > > o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if > needed to restrict bypass of DSCP values -- applicable to tunnel > mode SAs. This feature maps DSCP values from an inner header to > values in an outer header, e.g., to address covert channel > signaling concerns. > > describes that each SAD entry already has an entry telling which DSCP > values are allowed for this SA, i.e., the sender will sue this item to > put packets with given DSCP values to speific SA, but it also says > that receiver does NOT check those values. > > RFC4301 describes the behavior to work when DSCP is not part of the TS, that is in the absence of ts_dscp. When ts
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
(unless there is one SA per > DSCP > > value), i.e. which DSCP values can be grouped together. We group the DSCP > > values to limit the number of SAs > > > > Another fundamental reason is that if we are trying to make sure e.g. EF > traffic > > uses a separate child SA, we need that to apply in both directions. > Sure, one > > could configure both devices, and it probably wouldn't even matter if > they > > used different child SAs but if you do that, it is quite likely that we > would end > > up with 3 child SAs instead of two, as each end would set up an extra > one for > > EF, and not realize they could use the one the other end had set up. It > just > > works better if it is actually negotiated. > > > > > > - One omission in this draft is any discussion of the decapsulation > > procedure. According to 4301, we’re supposed to do a check of the > decrypted > > packet against the SAD selectors – is the DSCP included in that? How is > this > > handled in transport mode (where the original DSCP value would not be > > available)? Or, is transport mode forbidden to these SAs? > > > > > > Regarding to tunnel mode，due to the DSCP value already has the > > same/default policy (discard, if a packet that matches an SPD entry for > all > > components except the DSCP values would be treated as "not matching" on > > encryption), we can further discuss if/how to check of decryption packet > > against the SAD selectors. > > > > For transport mode, we prefer to say TS_DSCP doesn’t support transport > mode > > because we do not see the wide possibility of TS_DSCP being widely used > in > > transport mode. > > > > ___ > > 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] IETF 117 agenda items
With very limited connectivity. We sent a request probably a month ago for the following drafts. So just resending in case we missed anything. We are looking for these drafts to be adopted by the wg. https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/ https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/ Yours, Daniel On Wed, Jul 12, 2023, 00:06 Paul Wouters wrote: > > On Tue, Jul 11, 2023 at 4:52 PM Rebecca Guthrie 40uwe.nsa@dmarc.ietf.org> wrote: > >> Greetings, >> >> Will there be an adoption call for draft-smslov-ipsecme-ikev2-qr-alt-08? >> I support adoption, but if the group thinks it needs more discussion first, >> I'd like to request that it be added to the agenda. > > > We haven't really seen any further discussion other than at IETF-116. I > don't think anyone is objecting. I believe some people said an alternative > approach is to do a childless IKE SA and then do a CREATE_CHILD_SA with > PPK, but those people could still do that if they prefer and not implement > this draft. > > Note that libreswan and ELVIS+ have implemented this draft and done > interop testing. So I think we can have an adoption call with a quick (not > 4 month) WGLC after that. But I am not the chairs :/ > > Paul > > > > >> I have a few comments on the draft that I'm happy to share on list or as >> part of a discussion at IETF 117. >> >> Thanks! >> >> Rebecca >> >> Rebecca Guthrie >> she/her >> Center for Cybersecurity Standards (CCSS) >> Cybersecurity Collaboration Center (CCC) >> National Security Agency (NSA) >> >> -Original Message- >> From: IPsec On Behalf Of Tero Kivinen >> Sent: Monday, July 10, 2023 3:29 AM >> To: ipsec@ietf.org >> Subject: [IPsec] IETF 117 agenda items >> >> Send requests for IETF 117 IPsecME agenda items to the >> ipsecme-cha...@ietf.org by the end of this week, so I can create the >> agenda for the IPsecME WG next week. >> -- >> 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 >> > ___ > 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
[IPsec] Fwd: Fw: New Version Notification for draft-mglt-ipsecme-diet-esp-10.txt
Please find a new version we just uploaded to address editorial issues. Yours, Daniel From: internet-dra...@ietf.org Sent: Thursday, June 29, 2023 1:29 PM To: Carsten. Bormann; Carsten Bormann; Daniel Migault; David Schinazi; Tobias Guggemos Subject: New Version Notification for draft-mglt-ipsecme-diet-esp-10.txt A new version of I-D, draft-mglt-ipsecme-diet-esp-10.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-diet-esp Revision: 10 Title: ESP Header Compression Profile Document date: 2023-06-29 Group: Individual Submission Pages: 27 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-diet-esp-10.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp Diff: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-diet-esp-10 Abstract: ESP Header Compression Profile (EHCP) defines a profile to compress communications protected with IPsec/ESP. The IETF Secretariat -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] ESP compression with SCHC
Hi, Please find below a first version to compress ESP packets. We are expecting this draft to be adopted in the ipsecme WG but we do rely on the SCHC experts to ensure we are doing the right thing. [1] This version has undergone a major rewrite as all compression rules are now only expressed using SCHC. This ends by having a bit array that we need to pad appropriately to align to a byte array. We also simplified the profile. We expect to have a PoC based on OpenSCHC for IETF118. [2] leverage IKEv2 to negotiate the necessary parameters for the SCHC context. We are happy to present the draft in both WG. Any feedback is welcome! Yours, Daniel [1] https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-mglt-ipsecme-ts-dscp-02.txt
Please find an update with some additional text related to the traffic selectors for the SPD, SAD and the already existing DSCP Bypass, or DSCP values. We also recommend to copy the DSCP of the inner packet to the outer. Yours, Daniel From: internet-dra...@ietf.org Sent: Tuesday, April 18, 2023 1:53 PM To: Ulf Parkholm X; Harold Liu; Daniel Migault; Joel Halpern Subject: New Version Notification for draft-mglt-ipsecme-ts-dscp-02.txt A new version of I-D, draft-mglt-ipsecme-ts-dscp-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-ts-dscp Revision: 02 Title: Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) Document date: 2023-04-18 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-ts-dscp-02.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ts-dscp Diff: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-ts-dscp-02 Abstract: This document defines a new Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) as a traffic selector of the Security Policy Database (SPD). The new Traffic Selector type TS_DSCP consists of DSCP values associated to the negotiated SA. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-mglt-ipsecme-ts-dscp-01.txt
Hi, Please find below an updated version that addresses the feed backs received during the IET116 [1]. [1] https://datatracker.ietf.org/meeting/116/materials/minutes-116-ipsecme-202303290630-00 We added the following text to clarify how DSCP eases the traffic management: """ This causes both a resource issue - especially with hardware implementations that are designed with a limited number of SAs - as well operational and management issues. Typically, if the DSCP values are negotiated the initiator and the responder can agree to send a set of DSCP value over one SA and another set of DSCP value over a second channel. If DSCP values are not agreed and between (for example) 2 SAs, it is unlikely the initiator and the responder miraculously select the same subset of DSCP values over the same SAs. Instead each peer is likely that inbound and outbound traffic take different SA and as such does not solve the issue of discarding lower priority packets associated to different class of traffic sharing a given SA. This makes traffic management at least much harder as if not impossible. Increasing the number of SAs as to lower the traffic rate over each of these SA might reduce the probability of packet being dropped, but is not deterministic and as such cannot be considered as a solution especially when considering hardware with a hard limitation on the number of SAs. """ We also changed slightly the negotiation and provide additional text in the security consideration to prevent traffic that can potentially ends up in not being protected. """ A packet that matches an SPD entry for all components except the DSCP values would be treated as "not matching". If no other SPD entries match, the traffic might end up being transmitted in the clear. It is not different from ensuring that IP traffic is not sent in clear text and it is presumed that the IPsec subsystem itself would install a REJECT/DISCARD rule in the SPD to prevent that traffic from being transmitted without IPsec protection. To avoid such situation, it is RECOMMENDED to introduce a SP to does not consider the DSCP values after those SP specifying the DSCP. This is very similar to placing a default SP that protects all traffic by default. Upon receiving a TS_UNACCEPTABLE Error Notify or an incorrect response, the initiator MAY retry the IKEv2 negotiation without specifying the DSCP values. The initiator MAY handle the DSCP value on its own for outbound traffic, but MUST be prepared to receive any DSCP values from the responder """ Yours, Daniel From: internet-dra...@ietf.org Sent: Monday, April 17, 2023 9:10 AM To: Ulf Parkholm X; Daniel Migault; Joel Halpern Subject: New Version Notification for draft-mglt-ipsecme-ts-dscp-01.txt A new version of I-D, draft-mglt-ipsecme-ts-dscp-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-ts-dscp Revision: 01 Title: Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) Document date: 2023-04-17 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-ts-dscp-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ts-dscp Diff: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-ts-dscp-01 Abstract: This document defines a new Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) as a traffic selector of the Security Policy Database (SPD). The new Traffic Selector type TS_DSCP consists of DSCP values associated to the negotiated SA. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt
On Mon, Apr 17, 2023 at 4:51 AM Valery Smyslov wrote: > HI Daniel, > > > > thanks for the follow-up, please see inline (some text is snipped, where > we are in agreement). > > > > *From:* Daniel Migault [mailto:mglt.i...@gmail.com] > *Sent:* Friday, April 14, 2023 11:39 PM > *To:* Valery Smyslov > *Cc:* ipsec@ietf.org > *Subject:* Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt > > > > Hi Valery, > > > > Thanks for the follow-up please find inline my response to your comment. > Thank you for the clarifications and all my comments have been responded > to. > > > > Yours, > Daniel > > > > > > [snipped] > > > 1. Introduction and Overview > >A group key management protocol provides IPsec keys and policy to a >set of IPsec devices which are authorized to communicate using a >Group Security Association (GSA) defined in [RFC3740]. > > This is a nit but I believe that saying striaght forward > """ > This document presents an extension to >IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key >management. > > """ > > may be clearer. > > > > > > This is exactly what is written a few lines below in the same > para :-) > > Absolutely, as far as I remember, what I meant is that mentioning this > sentence in the beginning tells upfront what the draft is about. Starting > with the notion of groups management is I think not the reason we have the > draft. Again that was just a nit. > > > > OK, I moved this sentence to the beginning of the section. > > > thanks. >Large and small groups may use different sets of these protocols. >When a large group of devices are communicating, the GCKS is likely >to use the GSA_REKEY message for efficiency. This is shown in >Figure 1. (Note: For clarity, IKE_SA_INIT is omitted from the >figure.) > > ++ > +->| GCKS |<-+ > | ++ | > ||^| > |||| > || GSA_AUTH| > || or| > || GSA_REGISTRATION| > |||| > GSA_AUTH|| GSA_AUTH > or GSA_REKEY | or > GSA_REGISTRATION|| GSA_REGISTRATION > |||| > | ++-+ | > | |||| | > v vvvv v >+---++++---+ >| GM | ... | GM | ... | GM | >+---++++---+ >^ ^^ >| || >+---ESP---+---ESP--+ > >Figure 1: G-IKEv2 used in large groups > > > It might be helpful to indicate (inidvidual) IKE channel while the ESP SA > is shared between all GMs. > > > > I think that individual IKE SAs are already shown (GSA_AUTH or > GSA_REGISTRATION). Am I missing your point? > > Or do you want to change them to “IKE SA”? > > > > I do not remember what I had exactly in mind, but I think it might be to > indicate just IKE versus ESP to make it clear GSA messages are IKE > messages. > > > > I’m a bit unsure how to better do it. I’ve added labels > indicating IKE SAs, probably this suffice? > > Formally we should also label multicast communications, but I’m > not sure how to do it. > > Make them in double lines (==)? > unless there is something obvious to do, we can leave this as it is. >[snip] > > - Data Security SA (DATA): A multicast SA between each multicast > > source speaker and the group's receivers. There may be as many > > data SAs as there are multicast sources allowed by the group's > > policy. > > > >which I like more. Should we use this instead? > >Then the definition of Rekey SA must also be changed. > > > > I find it may be confusing to have policies in the definition of an SA, so > the second seems clearer
[IPsec] agenda time slot request
Hi, If the agenda permits we would like to present: * draft-liu-ipsecme-ikev2-mtu-dect "IKEv2 IPv4 Link Maximum Atomic Packet Notification Extension" * draft-mglt-ipsecme-ts-dscp "Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints " (to be published soon) Yours, Daniel -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
Hi, Thanks for the feedback. Please see below my comments/responses. Yours, Daniel On Sat, Jan 14, 2023 at 1:01 AM to...@strayalpha.com wrote: > Daniel, > > On Jan 13, 2023, at 8:33 PM, Daniel Migault wrote: > > f not, to better understand, do we have an example of a packet that cannot > be processed if the MTU is set to tunMAP but that can be processed if the > MTU is set to EMTU_R. > > > As per intarea-tunnels, MTU is a highly overloaded term. > > Tunnels relay packets that exceed their tunMAP but not their tunMTU > (EMTU_R - headers) using source fragmentation all the time. > correct, we need to remove encaps. However, that’s the issue. The reasons why what you’re trying to do isn’t > useful is already covered in detail in intarea-tunnels - and why not to do > it using IPv4 DF=0 in rfc6864. > > rfc6864 provides requirements of IP ID. DF=1 for inner and outer packet prevents using IP ID, but as mentioned DF=1 for outer is not possible in our case and I am not sure we can enforce DF=1 in the inner packet as well. Our proposal results in limiting fragmentation as well - when possible - and as such makes these requirements easier to meet. It’s not useful to have an email exchange rehashing that content message by > message. > > The conversation has been clarifying to us - at least regarding the terminology and we believe the document has improved, so that has been somewhat useful and we thank you for these feedbacks. While DF=1 is the recommended way, it is not an option for us - unless proven otherwise. **With DF=0**, we do measure some significant performance improvement by using our proposal and so far, I have been able to see any reasons for not doing it. If such reasons exist, it would be clarifying to explicitly mention them explicitly (to me and the WG) so these could be considered.. Joe > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
Hi, Thanks for the feedback, please find my comments and questions inline. Yours, Daniel On Fri, Jan 13, 2023 at 8:41 PM to...@strayalpha.com wrote: > Hi, Daniel, > > On Jan 13, 2023, at 2:12 PM, Daniel Migault wrote: > > Hi Joe, > > Thanks for the comment. There are some terminologies we were not using > properly, so thank you for the clarification. Please find inline our > clarification and implementation of your concerns. > > Yours, > Daniel > > On Sun, Jan 8, 2023 at 11:45 AM to...@strayalpha.com > wrote: > >> Hi, Daniel, >> >> The abstract clearly states a goal that is not achievable (of avoiding >> reassembly). The best way to avoid the impact of mid-tunnel fragmentation >> is to use IPv4 as a tunnel header the way that IPv6 would be - with DF=1. >> However, even so, the egress always needs to handle reasssembly as long as >> there is even source fragmentation. >> > > I understand the comment as our goal is interpreted to avoid > reassembling operations to happen completely. This would mean that > reassembly could even not be implemented. > This is not our intention. Reassembly happens the same way it happens > today. The only thing we do is that the egress node notify the ingress node > that reassembly is happening. The ingress node may or may not take any > action to prevent reassembly to happen with the next packets being tunneled > over the IPsec tunnel. In that sense "avoid" needs to be understood as > reducing the number of occurrences the reassembly operation happens. > > We may agree the best way to avoid mid tunnel fragmentation is to set > DF=1. But in our case we cannot meet this condition. > The current text in the abstract is > > OLD: > This document considers an ingress and an egress security gateway > connected over an IPv4 network. > The Tunnel Link Packet have their Don't Fragment (DF) set to 0. > > Does the text below is clearer to say: > > NEW: > This document considers an ingress and an egress security gateway > connected over a IPv4 network with the Tunnel Link Packet Don't Fragment > (DF) set to 0. > > > That is better English, but still technically ill-advised. Any solution > that requires IPv4 DF=0 then requires generation of unique IDs that don’t > wrap in ways that could cause mis-reassembly per RFC 6864. > > The introduction mentions the rationals on why we cannot rely on setting > DF=1. Typically some routers do not check the MTU and ignore the packet > without returning a ICMP PTB error and in many deployments the ICMP PTB -if > sent - is blocked and is not received. This prohibits the use of DF=1 with > IPv4. > > > You have described the reason why PLPMTUD exists, which is not a rationale > for continuing to use on-path IPv4 fragmentation. > > >> I appreciate what you WANT to do - but again, it is not possible. You >> have two behaviors - either use inner fragmentation (which won’t work for >> transit traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU. >> >> But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S >> of the tunnel ingress. If you reduce the tunnel MTU, you’re just going to >> end up black-holing packets arriving at the tunnel ingress. >> >> ok. I misunderstood tunnel MTU and that tunnel MTU is EMTU_R, this is > not what we are changing. What we had written might be confusing. > When I said EMTU_R I was considering the router only without any > consideration of the tunnel. From the terminology section of > intarea-tunnel I did not read EMTU_R applies to a tunnel environment, and > considered this to be the MTU associated to the interface for incoming > packet to the router. > > Here is what we actually meant: > > > We are ensuring that packet that are encapsulated by the Ingress interface > do not exceed the tunnel MAP. My understanding is that the tunnel MAP is > the largest IP packet the source can send, that will not be fragmented by > the network between the Ingress and egress interface. As it is not > fragmented, fragments will not be reassembled. > > > Please review intarea-tunnels. > > Setting Ingress send size to MAP doesn’t avoid source fragmentation, which > thus doesn’t avoid reassembly. It just sets the size of each fragment to > avoid on-path fragmentation - which avoids the need for DF=0. So setting > DF=0 is exactly what you don’t need. > > To do so, we set the MTU of the router associated with the Ingress > interface is set to the tunnel MAP. This corresponds to set tunMTU =tunMAP > Figure 11 of intarea. > > Suppose an IP packet is sent by the source and meets that router. > * The packet has DF=1. If it is larger th
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
tor of the source is able to
ensure that ICMP packet sent by the ingress router will be received by the
source. This only happens when DF=1 which supposes that MTU can be handled
as well as source fragmentation.
> The rest of the document is rife with further errors, e.g.:
>
> The last sentence of the abstract is incomprehensible.
>
> The last sentence of the abstract is:
"""
The ingress security gateway is expected to either perform (when possible)
Inner Fragmentation of to update Tunnel MTU.
"""
is the wording below clearer ?
"""
The ingress security gateway is expected to either use inner fragmentation
or consider the tunnel MAP as its tunnel MTU.
"""
>
> In the intro, the claims about IPv4 ID are incorrect. As noted in RFC6864,
> speed is not the issue but rather the expected reordering. Additionally,
> there’s already a timeout, so there is no requirement for indefinitely kept
> state. Further, given source fragmentation, such issues are irrelevant.
>
>
We mention high rates as ID collision requires a number of packets. Let
say, a link with 3 packets is very unlikely to result in an ID collision.
draft-ietf-intarea-tunnels in section 4.1.4 mentions high speed nodes as
well, so it is unclear what is wrong in our formulation below - but I
remain open to a clearer one.
"""
Then, as detailed in {{?RFC4963}}, {{!RFC6864}} or {{!RFC8900}}, the 16-bit
IPv4 identification field is not large enough to prevent duplication making
fragmentation not sufficiently robust at high data rates.
"""
DF=1 leads to black holing ONLY in the absence of PLPMTUD, which is the
> appropriate solution for IPsec tunnels anyway.
>
Again we are not considering the case where DF=1. Even though we were
considering DF=1, I am inclined that IPsec does not have PLPMTUD which
seems to indicate that DF=1 is subject to blackholing.
As far as I know there is no PLPMTUD defined for IPsec. The only document I
found was the following one:
https://www.ietf.org/archive/id/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01.txt
That said, with IPsec IKEv2 and ESP may take different paths so having
a PLPMTUD is likely to impact ESP and IKEv2. In addition, we are concerned
not by the MTU but the tunMAP.
In our case, we simply define a notification for IKEv2, which seems way
more simpler.
On the other hand, tunnel MTU does not prevent reassembly to occur.
It is correct that in addition to tunMAP we may also provide tunMTU to
prevent blackholing from happening at the egress gateway. The ingress node
will then be able to distinguish if the packet is discarded or fragmented.
Note that even if DF=0, black-holing could still occur if the Tunnel
> Transit packet exceeds the tunnel egress EMTU_R.
>
> The notification may look like:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Path Maximum Atomic Packet Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMTU_R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> On Jan 4, 2023, at 7:21 PM, Daniel Migault wrote:
>
> Hi Joe,
>
> We are waiting for your feedback, but I just want to check we have the
> same understanding and that we will have a feed back.
>
> We would like to understand if the terminology used in the document is
> aligned with the one of intarea-tunnels and if we agree that
> intarea-tunnels and IPsec have different perspectives on
> handling fragmentation. I do not see what we are proposing very different
> from what IPsec has been doing for years.
>
> I also think that everything is explained in the introduction (2 text
> pages), so you do not have to read the full document. The document is
> available here:
> https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/
>
> Yours,
> Daniel
>
> On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault
> wrote:
>
>> Hi Joe,
>>
>> So we just published an update of our draft. We try to catch up the
>> complete idea in the introduction - to avoid reading the complete draft. I
>> think we partly aligned with the tunnel document. The current version only
>> describe the security gateway as a node and does not split it between a
>> outer and an interface. I think for the remaining of the document we are
>> taking the exact terminology from the tunnel draft.
>>
>> We believe that IKEv2 and the tunnel document have different visions and
>> tried to highlight this also.
>>
>> One big clarification in my point of view is that the previous version
>> confused M
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
Hi Joe, We are waiting for your feedback, but I just want to check we have the same understanding and that we will have a feed back. We would like to understand if the terminology used in the document is aligned with the one of intarea-tunnels and if we agree that intarea-tunnels and IPsec have different perspectives on handling fragmentation. I do not see what we are proposing very different from what IPsec has been doing for years. I also think that everything is explained in the introduction (2 text pages), so you do not have to read the full document. The document is available here: https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/ Yours, Daniel On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault wrote: > Hi Joe, > > So we just published an update of our draft. We try to catch up the > complete idea in the introduction - to avoid reading the complete draft. I > think we partly aligned with the tunnel document. The current version only > describe the security gateway as a node and does not split it between a > outer and an interface. I think for the remaining of the document we are > taking the exact terminology from the tunnel draft. > > We believe that IKEv2 and the tunnel document have different visions and > tried to highlight this also. > > One big clarification in my point of view is that the previous version > confused MTU with MAP. > > We are happy to get your feedback. > > Yours, > Daniel > > On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com > wrote: > >> On Oct 31, 2022, at 11:07 AM, Daniel Migault wrote: >> >> >> - the tunnel has two DIFFERENT relevant MTUs >>> the egress reassembly MTU (EMTU_R), which is the only thing that should >>> drive the “tunnel MTU” >>> >>> the tunnel MTU, which the ingress needs to know for source >>> fragmentation, but is NOT relevant to the >>> origin MTU upstream of the ingress >>> >>> Will read the draft - but we believe that is better to generate one >> IPsec packet for every inner IP packet as opposed to two. This is why we >> are proposing to adjust the MTU so the outer packet matches the limit of >> the EMTU_R - and fragmentation be avoided. >> >> >> That doc explains why this is effort isn’t useful. As I noted to Tero, >> there’s no ICMP message that says “bigger than I’d like”. PTB means >> “packets larger than this will be dropped”. That’s not what’s going on >> here, so it’s the wrong message to support. >> >> There is no message that supports what you’re trying to do - perhaps >> because there can’t and shouldn’t be. >> >> Joe >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-08.txt
On Sun, Nov 27, 2022 at 2:03 PM Paul Wouters wrote: > On Wed, 23 Nov 2022, Tero Kivinen wrote: > > > I.e., the main reason being that group 2 was only MUST algorithm > > before, and moving it from MUST to MUST NOT while we do not have any > > oher algorithms as MUST was considered bad. Also the group is formed > > inin a deterministic way which should not make it possible that the > > group is created to be weak from the beginning. > > Right, so if we were to update 8247 (post ikev1 historicness), we should > do: > > * AES_GCM_16 from SHOULD to MUST > * AES_CBC from MUST to SHOULD > * 3DES from MAY to MUST NOT > > * PRF_HMAC_SHA1 from MUST- to SHOULD > > * AUTH_HMAC_SHA1_96 from MUST- to SHOULD > > It is tempting to speed it up to SHOULD NOT though SHA1 may not be a big issue there. > * 1024-bit MODP Group from SHOULD NOT to MUST NOT > * 1536-bit MODP Group from SHOULD NOT to MUST NOT > > Arguably, the SHA1 entries could go to MUST NOT because no one should > have ever had a need for those for IKEv2. > > Paul > > _______ > 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] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
Hi all, We proposed Joe to become a co-author, he refused as he said the review was done in his capacity of TSV area review and asked us to post this on the mailing list. Yours, Daniel On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault wrote: > Hi Joe, > > So we just published an update of our draft. We try to catch up the > complete idea in the introduction - to avoid reading the complete draft. I > think we partly aligned with the tunnel document. The current version only > describe the security gateway as a node and does not split it between a > outer and an interface. I think for the remaining of the document we are > taking the exact terminology from the tunnel draft. > > We believe that IKEv2 and the tunnel document have different visions and > tried to highlight this also. > > One big clarification in my point of view is that the previous version > confused MTU with MAP. > > We are happy to get your feedback. > > Yours, > Daniel > > On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com > wrote: > >> On Oct 31, 2022, at 11:07 AM, Daniel Migault wrote: >> >> >> - the tunnel has two DIFFERENT relevant MTUs >>> the egress reassembly MTU (EMTU_R), which is the only thing that should >>> drive the “tunnel MTU” >>> >>> the tunnel MTU, which the ingress needs to know for source >>> fragmentation, but is NOT relevant to the >>> origin MTU upstream of the ingress >>> >>> Will read the draft - but we believe that is better to generate one >> IPsec packet for every inner IP packet as opposed to two. This is why we >> are proposing to adjust the MTU so the outer packet matches the limit of >> the EMTU_R - and fragmentation be avoided. >> >> >> That doc explains why this is effort isn’t useful. As I noted to Tero, >> there’s no ICMP message that says “bigger than I’d like”. PTB means >> “packets larger than this will be dropped”. That’s not what’s going on >> here, so it’s the wrong message to support. >> >> There is no message that supports what you’re trying to do - perhaps >> because there can’t and shouldn’t be. >> >> Joe >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
Hi Joe, So we just published an update of our draft. We try to catch up the complete idea in the introduction - to avoid reading the complete draft. I think we partly aligned with the tunnel document. The current version only describe the security gateway as a node and does not split it between a outer and an interface. I think for the remaining of the document we are taking the exact terminology from the tunnel draft. We believe that IKEv2 and the tunnel document have different visions and tried to highlight this also. One big clarification in my point of view is that the previous version confused MTU with MAP. We are happy to get your feedback. Yours, Daniel On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com wrote: > On Oct 31, 2022, at 11:07 AM, Daniel Migault wrote: > > > - the tunnel has two DIFFERENT relevant MTUs >> the egress reassembly MTU (EMTU_R), which is the only thing that should >> drive the “tunnel MTU” >> >> the tunnel MTU, which the ingress needs to know for source fragmentation, >> but is NOT relevant to the >> origin MTU upstream of the ingress >> >> Will read the draft - but we believe that is better to generate one IPsec > packet for every inner IP packet as opposed to two. This is why we are > proposing to adjust the MTU so the outer packet matches the limit of the > EMTU_R - and fragmentation be avoided. > > > That doc explains why this is effort isn’t useful. As I noted to Tero, > there’s no ICMP message that says “bigger than I’d like”. PTB means > “packets larger than this will be dropped”. That’s not what’s going on > here, so it’s the wrong message to support. > > There is no message that supports what you’re trying to do - perhaps > because there can’t and shouldn’t be. > > Joe > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Virtual interim about re-designing ESP?
I agree. The point I wanted to make is that multicore can be made for both in ESPv3 and in ESPv4 so we do not wait for ESPv4 to handle multicore. The two mechanisms may be slightly different but I expect some commonalities. As a result, I expect early deployments on ESPv3 may provide some useful feedback for ESPv4. On Wed, Nov 23, 2022 at 2:03 AM Steffen Klassert < steffen.klass...@secunet.com> wrote: > On Tue, Nov 22, 2022 at 05:16:08PM -0500, Daniel Migault wrote: > > I support Bob's suggestion. > > I also believe that multicore will be addressed by design. I do want to > > have some mechanisms like [1] to be included by design. That said, I > would > > like [1] to start on ESPv3 and take the output back to ESPv-4 as opposed > to > > waiting for ESP-v4. > > I disagree. If we touch ESP, everything should be on the table and > we should consider that all together. > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance
Hi Steffen, I think I mostly agree with you. Please see inline, Yours, Daniel On Wed, Nov 23, 2022 at 1:36 AM Steffen Klassert < steffen.klass...@secunet.com> wrote: > On Tue, Nov 22, 2022 at 04:58:55PM -0500, Daniel Migault wrote: > > This draft is missing an important part which is the actual negotiation > > of the multiple SAs. A peer willing to set these multiple SAs will have > to > > negotiate them anyway. Some implementations can > > handle parallel CREATE_CHILD_SA others cannot and the negotiation of > > multiple SAs might take a very long time, at least a time that is not > > acceptable to high performance tunnels. Since these child SAs need to be > > created, the one willing to the multiple SAs can simply start and stop > when > > the responder says stop. In terms of IKEv2 the gains are minimal. The > > document may add a mechanism similar to address that: > > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-multiple-child-sa/ > > I'm one of the authors of the above mentioned draft and the draft > we are discussing here. > > Speaking as an author of the above mentioned draft: > > This draft was a first attempt so solve the multi cpu SA case. > The mechanism to install all child SAs once that was used there > was seen as as too complex, given that the number of cpus are > not too high. So it should be possible to either create > separate parallel child SAs, or creating them on demand when > traffic pops up an a certain cpu. > The draft we discuss here takes this into account and > reduces the complexity to a minimum. I agree but in my opinion the draft has some scalability limitation and to be useful needs to be combined with something else - at least this is my understanding. Maybe I am biased as the use case it may address is not the one we have. Do not get me wrong, I think the work has been useful and should be documented. But I think that the alternative that limits the number of SA is very attractive, especially for our hardware implementations with a limited number of SA. > > However, draft-ponchon-ipsecme-anti-replay-subspaces addresses all of > these > > issues nicely and provides a much more scalable solution. It basically > > makes -IMO - both -multiple-child-sa and -multi-sa-performance obsolete. > > I disagree here. The multi-sa-performance draft just adds two IKE > notifications, so no achitectural changes. This is the 'low hanging > fruit', it can be done independent of any changes to ESP. > > The anti-replay-subspaces draft does architectural changes to ESP, > this needs more work. > > I agree that the advantage of the draft is that it is a very ow hanging fruit but on the other hand - at least as I see it - -ponchon-ipsecme-anti-replay-subspaces provides a complete solution to the scalability concern we have. > > My suggestion is that -multi-sa-performance is being moved to > experimental > > and almost shipped as it is so the work being achieved is documented. > This > > has been some interesting work, but today, I would like the group to > spend > > more cycles on draft-ponchon-ipsecme-anti-replay-subspaces that I > consider > > more promising. > > I already proposed to work on a ESP-v4 version, and this draft should > definitely be considered there. But the discussion about ESP-v4 should > be open, and not focused on this particular proposal. > > I agree ESP-v4 should be considered natively, but I would like -ponchon-ipsecme-anti-replay-subspaces to be implemented with the current ESP mostly so we do not wait ESP-v4 to have it. Actually at Ericsson we would like to implement the standard version of -ponchon-ipsecme-anti-replay-subspaces in a reasonable delay -- i.e. next year. To clarify my position I am not opposed to the adoption of the draft. My position is that it gets published as soon as possible as an experiment that paves the way for a more complete solution. In other words, I think we should not have the document being discussed for years in the WG. -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME WG Adoption call for draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
I support its rapid publication. Yours, Daniel On Tue, Nov 22, 2022 at 1:22 PM Michael Richardson wrote: > > I have read draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt in it's various > forms over the years, and again just now. > I support adoption of the document and rapid publication. > > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > 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] Virtual interim about re-designing ESP?
I support Bob's suggestion.
I also believe that multicore will be addressed by design. I do want to
have some mechanisms like [1] to be included by design. That said, I would
like [1] to start on ESPv3 and take the output back to ESPv-4 as opposed to
waiting for ESP-v4.
Interims are free, we can be flexible and have a mix of presentations /
discussions.
Yours,
Daniel
[1] ponchon-ipsecme-anti-replay-subspaces-00
<https://datatracker.ietf.org/doc/draft-ponchon-ipsecme-anti-replay-subspaces/>
On Tue, Nov 22, 2022 at 4:59 PM Michael Richardson
wrote:
>
> Paul Wouters wrote:
> >> - How should the problems be solved?
> >>
>
> > Once we have a list, I think we can come up with plans to tweak ESP
> to
> > tick off our list items.
>
> > I do think we need some short presentations for an interim. Just
> having
> > a free flow discussion will probably not be very useful.
>
> We need a candidate list of items, then a slide / github issue per item,
> and
> then we need to discuss enough such that all people have a deep
> understanding
> of that item.
>
> It could be that we have items which were duplicate, and it could also be
> that we have goals which are really two goals.
>
> {I think we are in complete agreement about how such a virtual interim
> should go}
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___________
> 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] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance
This draft is missing an important part which is the actual negotiation of the multiple SAs. A peer willing to set these multiple SAs will have to negotiate them anyway. Some implementations can handle parallel CREATE_CHILD_SA others cannot and the negotiation of multiple SAs might take a very long time, at least a time that is not acceptable to high performance tunnels. Since these child SAs need to be created, the one willing to the multiple SAs can simply start and stop when the responder says stop. In terms of IKEv2 the gains are minimal. The document may add a mechanism similar to address that: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-multiple-child-sa/ However, draft-ponchon-ipsecme-anti-replay-subspaces addresses all of these issues nicely and provides a much more scalable solution. It basically makes -IMO - both -multiple-child-sa and -multi-sa-performance obsolete. My suggestion is that -multi-sa-performance is being moved to experimental and almost shipped as it is so the work being achieved is documented. This has been some interesting work, but today, I would like the group to spend more cycles on draft-ponchon-ipsecme-anti-replay-subspaces that I consider more promising. Yours, Daniel On Tue, Nov 15, 2022 at 10:51 PM Panwei (William) wrote: > Hi, > > I've read this draft and support the adoption. > > Regards & Thanks! > Wei PAN (潘伟) > > > -Original Message- > > From: IPsec On Behalf Of Tero Kivinen > > Sent: Thursday, November 10, 2022 1:35 AM > > To: ipsec@ietf.org > > Subject: [IPsec] IPsecME WG Adoption call for > > draft-pwouters-ipsecme-multi-sa-performance > > > > This is two week working group adoption call for the > > draft-pwouters-ipsecme-multi-sa-performance. If you support adoption of > this > > document to the IPsecME WG send email to the list before the 2022-11-24. > > > > Note, that this is starting point for the document, so if you have any > comments > > send them to list also. > > > > There is no specific item for this in our charter, but this should > > (now) be small enough change to fit in the "minor extensions" > > category... > > -- > > 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] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
Hi, see below some clarifications. On Mon, Oct 31, 2022 at 12:18 PM to...@strayalpha.com wrote: > See below in-line. > > On Oct 31, 2022, at 8:53 AM, Daniel Migault wrote: > > > > On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com < > to...@strayalpha.com> wrote: > >> HI, Tero, et al,, >> >> Thanks for the clarification; I now understand that what you really are >> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a >> signal. That’s a mistake, IMO, largely because it serves only IPv4. >> >> My understanding is that IPv6 performs fragmentation at the source, in > which case, the receiving gateway does not need to defragment. > > > Both IPv4 and IPv6 use source fragmentation, which cannot be avoided for > tunnels (see intarea-tunnels). > > There are two sources (please review intarea-tunnels); please explain more > clearly which one you mean. > > The original source of the packet (outside the tunnel) does source > fragmentation. This doesn’t impact the IPsec egress (please - not > “receiving gateway” - that could refer to ANY router on the path, either > outside the tunnel or inside the tunnel; note that it does NOT actually > refer to the IPsec egress because IPsec could be implemented as “bump in > the wire” and its endpoints might not be gateways at all). > > But *so does the IPsec ingress*. It fragments the tunnel packets (again, > see intarea-tunnels). It is THOSE packets the IPsec egress reassembles. > > Our problem is only happening with IPv4 when an on-path router fragments > and the receiving security gateway needs to re-fragment. > > > You should already stop using on-path *TUNNEL* hop refragmentation (again, > router here is ambiguous). > > The “receiving gateway” is the IPsec egress of this traffic. Why do you > keep saying it needs to refragment? It *reassembles* the tunnel fragments > (but it has to - source fragmentation is always possible and will always > need to be supported). > > I agree we are not concerned by source fragmentation but by on-path *TUNNEL* hop refragmentation. We know these should nor be used, but it is used and we have to deal with it. This is the scope of our document. > We explicitly mention in the introduction that what we have is not a > PLPMTUD for IPsec. > > > Understood. But here’s the issue: > > - the end-to-end path can and should be using PLPMTUD > having your system find a way for IPsec ingresses to generate *more* ICMP > PTBs is not a solution, > as you already note (because they’re untrusted, dropped, or not generated > in the first place) > > - the tunnel has two DIFFERENT relevant MTUs > the egress reassembly MTU (EMTU_R), which is the only thing that should > drive the “tunnel MTU” > > the tunnel MTU, which the ingress needs to know for source fragmentation, > but is NOT relevant to the > origin MTU upstream of the ingress > > Will read the draft - but we believe that is better to generate one IPsec packet for every inner IP packet as opposed to two. This is why we are proposing to adjust the MTU so the outer packet matches the limit of the EMTU_R - and fragmentation be avoided. Tunnels fragment and reassemble. There is no way to avoid that or to tune > to that, *if you implement your tunnel properly, that fact is and needs to > be invisible* to the endpoints. > > Or do you want your endpoints sending 48B payloads when you transit ATM > links too (they do still exist)? > > Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe > a PLPMTUD can be built on top of it, but we would like to avoid taking that > path for now. > > > Please review intarea-tunnels. Signals inside the tunnel are not always > appropriate to relay outside the tunnel. > > But the really confusing part here is that you admit that ICMP doesn’t > work, but you’re designing a system to detect (the wrong) info to send in > ICMPs. > What we are saying is that ICMP does not work because the message and its information is *not* received - that is it is not generated, discarded and in the best case not trusted. Using the IKEv2 channel achieves this. The other part of the discussion is what to do once the gateway has that information. We do list source fragmentation, which requires no interaction with the peers sending the to-become-inner packet. On the other hand, we believe - and maybe we are wrong - that it would be better to avoid the fragmentation and ask the source of the inner packet to adjust its MTU and send smaller packets. To do so we suggest using ICMP - which is the trusted network. As the ICMP is coming from the IKEv2 gateway, it is plausible that this packet reaches the source of the inner packet. > > Joe > > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
So to clarify, the draft is mostly carrying the necessary information so the gateway can deal with fragmentation in its network using whatever means is needed. The use of ICMP PTB was only a suggestion, other mechanisms may be used. The definition of such a mechanism is outside of ipsec and the draft. Our understanding is that unless there is no such mechanism the draft has some value. Yours, Daniel On Mon, Oct 31, 2022 at 11:59 AM Joe Touch wrote: > +1 > > > On Oct 31, 2022, at 8:37 AM, Michael Richardson > wrote: > > > > > > Tero Kivinen wrote: > >> My understanding is that this draft (which I have not yet properly > >> read) is solving the situation where the tunnel does not get ICMP PTB > >> messages as they are forwarding packets with DF bit set to 0, and then > >> the receiving end will see extra fragmentation happening for the > >> packets. Then the receiving end will simulate the ICMP PTB by sending > >> authenticated IKEv2 notification that tells the sending end that his > >> packets got fragmented. > > > > While I think that the authors think they are solving this problem, I > think > > that what they have created is a protocol for dealing with fragmentation > > beyond the far gateway. > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > ___ > > 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] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
I think Michael is correct. The problem comes from the fragmentation of the outer IPv4 packet. The inner packet might be IPv4 or IPv6 and the security gateway may use any possible means to ask the nodes to adjust their MTU. Currently we suggest using ICMP PTB, but if RFC9268 also provides some means to do it, we do not want to prevent using it. We currently believe that this may be up to the gateway to decide what to do, so we do not necessarily require any use mechanism to be normative - but that point may evolve depending on what the WG decides. Yours, Daniel On Mon, Oct 31, 2022 at 11:37 AM Michael Richardson wrote: > > Tero Kivinen wrote: > > My understanding is that this draft (which I have not yet properly > > read) is solving the situation where the tunnel does not get ICMP PTB > > messages as they are forwarding packets with DF bit set to 0, and > then > > the receiving end will see extra fragmentation happening for the > > packets. Then the receiving end will simulate the ICMP PTB by sending > > authenticated IKEv2 notification that tells the sending end that his > > packets got fragmented. > > While I think that the authors think they are solving this problem, I think > that what they have created is a protocol for dealing with fragmentation > beyond the far gateway. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > 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] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com wrote: > HI, Tero, et al,, > > Thanks for the clarification; I now understand that what you really are > seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a > signal. That’s a mistake, IMO, largely because it serves only IPv4. > > My understanding is that IPv6 performs fragmentation at the source, in which case, the receiving gateway does not need to defragment. Our problem is only happening with IPv4 when an on-path router fragments and the receiving security gateway needs to re-fragment. We explicitly mention in the introduction that what we have is not a PLPMTUD for IPsec. Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe a PLPMTUD can be built on top of it, but we would like to avoid taking that path for now. > To the authors, again please see intarea-tunnels. The terms used here are > ambiguous - “downstream” of a tunnel means traffic as it leaves the egress, > but “downstream’ of the ingress could mean either that or the tunnel path > itself (both are downstream). > > > On Oct 31, 2022, at 4:18 AM, Tero Kivinen wrote: > > > > to...@strayalpha.com writes: > >>In the best case scenario, the security gateway informs the source > node to > >>reduce the size of the inner packet with an ICP PTB packet for > example. > >> > >> How? It can’t send an ICMP because it doesn’t have *the* packet causing > the > >> problem to “reflect” back to the source. The ingress may not know who > the > >> source is (there may be thousands or millions of sources). So which > source? > > > > The normal case to do that is that IPsec SGW keeps track of the size > > of packets that are ok, and which are too big based on the information > > it receives. I.e., it might have received unsecured ICMP PTB message > > from the network for its own Child SA, but only knows the SPI of the > > Child SA, not who was the original sender. So it keeps track that for > > this SPI the ESP packets cannot be larger than xxx bytes. > > > > Next time it receives a packet from the source and when it is > > encrypting it, it will verify that it will fit the size set for that > > Child SA, and if it is too big, it will generate ICMP PTB for that > > specific packet. > > > > IPsec gateways have been doing that for years, and this has been > > described in the RFC4301 section 8.2.1. > > That would happen because the tunnel packet caused PTB. This case is > described in intarea-tunnels 4.3.2. The way in which IPsec gets it wrong > (IMO) is described in Section 4.3.1 and is related to RFC 3884, e.g., by > subsuming the functions of a router inside the IPsec mechanism, rather than > operating strictly as a tunnel, which should be represented as a link - and > *links do not send ICMP messages. > > What SHOULD happen in IPsec is that the SPI should have an MTU (being a > link) and the *router* where packets are forwarded into the tunnel should > determine when packets that want to enter that link are too big - at which > point, per RFC 1812, the *router* should be sending the ICMP. > > > My understanding is that this draft (which I have not yet properly > > read) is solving the situation where the tunnel does not get ICMP PTB > > messages as they are forwarding packets with DF bit set to 0, and then > > the receiving end will see extra fragmentation happening for the > > packets. Then the receiving end will simulate the ICMP PTB by sending > > authenticated IKEv2 notification that tells the sending end that his > > packets got fragmented. > > The only reason the packet would have been too big at the receiver is if > it were to exceed the receiver’s reassembly buffer. That’s not what’s > happening here. > > It seems like there’s confusion about the fact that the source can somehow > avoid fragmentation of the tunneled packets. That can’t happen - see > intarea-tunnels Sec 3.6.3. Source fragmentation can and must still occur. > The receiver should never send PTBs for 64-byte IPv4 packets (or 1280B > IPv6). > > Further, on-path fragmentation for IPv4 has been warned against (the > source has to rate-limit to avoid ID reuse during expected reordering, per > RFC 6864). > > > Now the sending end can do similar processing of this information that > > it does for unauthenticated ICMP PTB messages received for ESP > > packets. > > Receiving a fragment isn’t a PTB event, though, as noted above. > > > -- > > kivi...@iki.fi > > > > ___ > > 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] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
pect the security gateway to "translate" that information to the source of the inner packet. A huge advantage of such information is that it is being transmitted by the ingress IPsec security gateway to the IPsec egress security gateway over a secure channel. In our opinion this adds at least some value over the ICMP PTB.In terms of information I tend to agree that this information is similar except that that information can be assumed to be received by the other security gateway. Even if it were, then the tunnel ingress would be sending more fragments > (at the tunnel ingress by source-fragmented at the outer header); it can’t > change the MTU of the origin packets it happens to receive — that happens > at the packet origin, which can be upstream of the ingress, or at a minimum > is outside the scope of IPsec (even if the ingress and packet origin are a > the same node). > > I do see two aspects. On that one security gateway provides some information regarding its processing related to IPsec. At the very least informing the egress security gateway that it straffic is causing a DDoS seems in scope. Now, it is also correct that providing such information if no action can be taken is not very useful. In our case, we do mention some actions that can be taken and one of these actions is that the security gateway sends an ICMP PTB message. It is unclear to me if that is what you are mentioning as out of scope of IPsec. I see this as similar to a router that needs to fragment and sends to the source an ICMP PTB packet. > What exactly is this a solution for? > The solution is to avoid the receiving gateway to re-fragment. > > Joe > — > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > > ___ > 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] Scheduling for London
We would like to add - if time permits: * Traffic Selector with DSCP * Follow-up with MTU fragmentation Yours, Daniel On Sun, Oct 30, 2022 at 6:00 PM Yoav Nir wrote: > Hi, folks. > > As you know, we have a 90-minute session on Wednesday, November 9th at > 15:00. > > In addition to all the document status and solemn recitation of the Note > Well, we have so far received 4 requests for agenda time: > > > >1. From Hang Shi about draft-ls-6man-ipcomp-exclude-transport-layer, a >proposed extension to IPComp >2. New IKEv2 payload format - by Valery >3. Revised Cookie processing >(draft-smyslov-ipsecme-ikev2-cookie-revised) - also by Valery >4. Inter-domain source address validation using RPKI and IPsec >(draft-xu-risav and draft-xu-erisav) - by Yangfei Guo > > > If anyone else needs an agenda slot, now is the time to speak. > > Thanks > > > ___ > 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] negotiating DSCP in TS with IKEv2
I expected this question to be answered on the mailing list. I would like this question being at the ipsecme agenda. Yours, Daniel On Mon, Oct 24, 2022 at 2:41 PM Daniel Migault wrote: > Hi all, > > We are looking at establishing SAs for specific DSCP values. I am > wondering if the specification of specific TSi/r is the right way to do > this or if that issue has already been solved. > > Yours, > Daniel > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] negotiating DSCP in TS with IKEv2
Hi all, We are looking at establishing SAs for specific DSCP values. I am wondering if the specification of specific TSi/r is the right way to do this or if that issue has already been solved. Yours, Daniel -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)
Hi Tero, This is correct. When reading Paul's comment I had in mind the text was about the SN roll over. However, re-reading the full section this is not the case and the SN roll over mechanism is described later in the section. I propose to simply remove the current text "Note ... " Yours, Daniel On Wed, Jul 20, 2022 at 4:20 PM Tero Kivinen wrote: > Paul Wouters writes: > > > The sequence number discussion mentions the issue of packets > falling > > > out of the receive window. We talked about an IKE option/notify > to > > > signal this and during that discussion it also came to light > that this > > > protocol is going to be used without IKEv2. This leaves an > > > interoprability unaddressed. > > > > > > I do not see any mention of IKE option and SN, but maybe you can > > > refresh my memory. > > > > Without signaling that this is going to use large jumps in the SN, the > > other end would drop packets outside of its replay window. If there is > > no IKE, how is the peer going to know about this? eg you write: > > > > Note that standard receivers are generally configured with > > incrementing counters and, if not appropriately configured, the use > > of a significantly larger SN than the previous packet can result in > > that packet falling outside of the peer's receiver window which could > > cause that packet to be discarded. > > I think this description is incorrect. Any kind of jumps in the SN > will NOT cause any packets to be dropped unless there is reordering > happening between the incoming packets. > > It you are using the time based sequence numbers then the difference > between sequence numbers will be large if there has been lots of time > between two packets, and reordering which causes one packet to be > delayed for that long is uncommon. > > I.e. if properly implemented IPsec implementation gets sequence > number which is much larger than previous sequence the recipient will > simply move the replay window there and will drop only frames which > has old sequence numbers that are older than this last received > sequence number - replay window size. > > To receive such frame would require reordering of frames, and to cause > issues the delayed frame needs to be delayed for time based sequnce > number interval * replay window size. > > This all of course assumes that the sequence number is not trying to > jump forward more than 2^31... > > > What you wrote is "this is a problem". Instead, I think you should state > > something like "Using time based SN should only be used when it is known > > that the remote peer supports this or when it is known that anti-replay > > windows are disabled". > -- > kivi...@iki.fi > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)
Hi Paul, Thanks for the response. Please see my responses inline. Yours, Daniel On Tue, Jul 19, 2022 at 11:47 AM Paul Wouters wrote: > On Mon, 18 Jul 2022, Daniel Migault wrote: > > > The limited SPI numbers and rekeying is still not clear to me. > > We exchanged a few emails but that did not result in me > understanding > > this. > > > > > > I am happy to understand what is unclear. I suppose the text you are > referring to is the one below - extracted from version 11. > > > >Alternatively, some constrained devices will not implement IKEv2 or > >Minimal IKEv2 and as such will not be able to manage a roll-over > >between two distinct SAs. In addition, some of these constrained > >devices are also likely to have a limited number of SAs - likely to > >be indexed over 3 bytes only for example. One possible way to enable > >a rekey mechanism with these devices is to use the SPI where for > >example the first 3 bytes designates the SA while the remaining byte > >indicates a rekey index. SPI numbers can be used to implement > >tracking the inbound SAs when rekeying is taking place. When > >rekeying a SPI, the new SPI could use the SPI bytes to indicate the > >rekeying index. > > I don't understand what it is that the devices are trying to do. Both in > terms of saving CPU or energy, and in terms of interpreting bytes of the > protocol. Can you give a full example of a rekey taking place in the > traditional way and in this new way proposed here? Perhaps when I see > that, I can help with modifying the above text to make this process > clear? > > The device could be provisioned with a master secret from which keys are derived. It uses one byte of the SPI to indicate which key is in use. The other peer is provisioned the same way and can generate the appropriate key. This rekey improves the use case of a device (without IKEv2) only provisioned with a single key while avoiding the management of multiple SAs - especially when the rekey occurs. Typically a rekey performed by IKE creates a new SA and deletes the previous one. Let me know if the proposed text is clearer. OLD SPI numbers can be used to implement tracking the inbound SAs when rekeying is taking place. When rekeying a SPI, the new SPI could use the SPI bytes to indicate the rekeying index. NEW This enables indicating both the SA and the key being used for the packet. When the last byte of the SPI changes, the device generates or retrieves the corresponding key and assigns it to the SA. > > The sequence number discussion mentions the issue of packets > falling > > out of the receive window. We talked about an IKE option/notify to > > signal this and during that discussion it also came to light that > this > > protocol is going to be used without IKEv2. This leaves an > > interoprability unaddressed. > > > > I do not see any mention of IKE option and SN, but maybe you can refresh > my memory. > > Without signaling that this is going to use large jumps in the SN, the > other end would drop packets outside of its replay window. If there is > no IKE, how is the peer going to know about this? eg you write: > > Note that standard receivers are generally configured with > incrementing counters and, if not appropriately configured, the use > of a significantly larger SN than the previous packet can result in > that packet falling outside of the peer's receiver window which could > cause that packet to be discarded. > > What you wrote is "this is a problem". Instead, I think you should state > something like "Using time based SN should only be used when it is known > that the remote peer supports this or when it is known that anti-replay > windows are disabled". > > I added your text while keeping the description of the problem. > > The only IKE option discussion I recall of is an option you propose to > > request the other peer not to send dummy packets - which is primarily > out of scope of minimal esp and whose usefulness remains to be proven. > > It was in relation to AEAD security. > > I did talk about using IKEv2 to convey some of these recommendations > via IKEv2 so peers can become aware of these instead of the more vague > wording the draft now uses that basically assumes all peers involved > do minimal ESP. It is fine for you not to take up this suggestion. > > > And since this protocol is also meant to run without IKEv2, there > is > > an issue of only recommending AEAD algorithms that rely on IKEv2 > for > > its security properties. > > > > > > I do not see t
Re: [IPsec] [Lwip] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)
Hi Paul, Looking at the history, my latest comments were sent on april 25, and following your email of may 24, I published the version 11 [1] that reflected the april changes. (This version should have been published earlier but was stalled into the data tracker.) So considering the latest version published, please see my response inline to your comments. [1] https://www.ietf.org/archive/id/draft-ietf-lwig-minimal-esp-11.txt Yours, Daniel On Mon, Jul 18, 2022 at 3:31 PM Paul Wouters wrote: > On Mon, 18 Jul 2022, Daniel Migault wrote: > > > My reading of the datatracker is that the document in IESG > Evaluation::AD Followup for 117 days. I do not see any follow-up with the > following email from > > may 25 with the latest changes and believe all concerns have been > addressed. I am wondering what prevents the document from being sent to the > RFC queue > > and if there is anything expected from my side. > > See my last email to you: > > Date: Tue, 24 May 2022 11:27:28 > From: Paul Wouters > To: Daniel Migault > Subject: draft-ietf-lwig-minimal-esp > > > Hi Daniel, > > Just a reminder that draft-ietf-lwig-minimal-esp is waiting on > actions > on your end to resolve the DISCUSS items. While discussing in > github is > useful, in the end the changes do need to go into a new draft > version > for the DISCUSS holders to evaluate them. > > I think the biggest unresolved issue is the SPI one with using > just a > few bytes and the "indexing" that I still do not understand. > > Paul > > > The limited SPI numbers and rekeying is still not clear to me. > We exchanged a few emails but that did not result in me understanding > this. > I am happy to understand what is unclear. I suppose the text you are referring to is the one below - extracted from version 11. Alternatively, some constrained devices will not implement IKEv2 or Minimal IKEv2 and as such will not be able to manage a roll-over between two distinct SAs. In addition, some of these constrained devices are also likely to have a limited number of SAs - likely to be indexed over 3 bytes only for example. One possible way to enable a rekey mechanism with these devices is to use the SPI where for example the first 3 bytes designates the SA while the remaining byte indicates a rekey index. SPI numbers can be used to implement tracking the inbound SAs when rekeying is taking place. When rekeying a SPI, the new SPI could use the SPI bytes to indicate the rekeying index. > The sequence number discussion mentions the issue of packets falling > out of the receive window. We talked about an IKE option/notify to > signal this and during that discussion it also came to light that this > protocol is going to be used without IKEv2. This leaves an > interoprability unaddressed. > > I do not see any mention of IKE option and SN, but maybe you can refresh my memory. The only IKE option discussion I recall of is an option you propose to request the other peer not to send dummy packets - which is primarily out of scope of minimal esp and whose usefulness remains to be proven. > And since this protocol is also meant to run without IKEv2, there is > an issue of only recommending AEAD algorithms that rely on IKEv2 for > its security properties. > I do not see the issue associated with AEAD, so can you be a bit more explicit. I do not see what is being provisioned via IKE that cannot be provisioned via other means. In addition, I do not see this as an issue if we were mandating AEAD. This is not the case. The document recommends the use of AEAD as a general purpose. I think this is relevant and does not prevent specific cases of not using AEAD. What text would you like to see ? > Section 6 talks about Dummy packets but the labeling of the header > is a bit misleading into thinking the Next Header behaviour is > modified. I had suggested the section to be renamed. > > The current title is "6. Next Header (8 bit) and Dummy Packets". The section has been renamed, and I do not see what more needs to be done. > > Please find my response to your comments. The current version of the > file integrates the language changes as well as changes to address the > concerns > > of this thread: > > > > > https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/d7710c19802bdce4c978d71ad303b739e1406f1e > > We ended up discussing this in email, but that did not end in my > understanding. Also, the above commit did not actually make it > into the draft yet. It is very hard as AD to keep track of changes > that are not in the actual datatracker. > The changes have been implemented here: https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ > Paul -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)
Hi all, My reading of the datatracker is that the document in IESG Evaluation::AD Followup for 117 days. I do not see any follow-up with the following email from may 25 with the latest changes and believe all concerns have been addressed. I am wondering what prevents the document from being sent to the RFC queue and if there is anything expected from my side. Yours, Daniel On Mon, Apr 25, 2022 at 2:19 PM Daniel Migault wrote: > Hi Paul, > > Please find my response to your comments. The current version of the file > integrates the language changes as well as changes to address the concerns > of this thread: > > > https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/d7710c19802bdce4c978d71ad303b739e1406f1e > > Yours, > Daniel > > On Tue, Apr 12, 2022 at 5:10 PM Paul Wouters > wrote: > >> >> On Tue, Apr 5, 2022 at 10:09 PM Daniel Migault >> wrote: >> >>> Hi Paul, >>> >>> Thanks for commenting. Please find my responses below. >>> >>> Section 2: >>> >>>> >>>> It suggests a partial SPI match can be used, based on the assumption >>>> that >>>> the SPI number is known to have mostly zeros because the device only >>>> uses >>>> a hardcoded limited set (eg 257 to 260). While this is true for the >>>> outbound >>>> SPI, this may not be true for the inbound SPI, especially if the peer >>>> is not >>>> a "minimal ESP" device but a regular multipurpose OS. I think some >>>> clarification >>>> is needed for this minimum implementation optimization. >>>> >>>> >>> I probably missed the comment. I understand that a partial SPI match >>> would mean that only a subset of bytes will be considered, but I cannot >>> find text that suggests it. I do not also see any mention of special values >>> for the SPI. I also understand from the comment that the text is suggesting >>> some SPI values but I cannot find what text suggests it - at least for a >>> very small subset. >>> >> >> This was based on: >> >> The index may be based on >> the full 32 bits of SPI or a subset of these bits. >> >> >> If you index it on a partial length, you need to have generated these as >> well with reduced length or else this operation would not provide unique >> indexes. >> >> And you are not generating the peer's SPI, so those indexes need to use the >> full 32 bit too. >> >> Perhaps you mean to say that for indexing your own generated SPIs, you might >> know you only need to look at a subset of bytes? >> >> Perhaps you can clarify the indexing sentence ? >> >> The SPI field (4 bytes) is decoupled between the SPI value (3 bytes) and > a rekey index (1 byte). > > Here is the text that I believe addresses your concern: > """ > Alternatively, some constrained devices will not implement IKEv2 or > Minimal IKEv2 and as such will not be able to manage a roll-over between > two distinct SAs. In addition, some of these constrained devices are also > likely to have a limited number of SAs - likely to be indexed over 3 > bytes only for example. One possible way to enable a rekey mechanism with > these devices is to use the SPI where for example the first 3 bytes > designates the SA while the remaining byte indicates a rekey index. > > SPI numbers can be used to implement tracking the inbound SAs when > rekeying is taking place. When rekeying a SPI, the new SPI could use the > SPI bytes to indicate the rekeying index. > """ > >> >> >>> [2] >>>> >>>> Section 2.1: >>>> >>>>SPI that are not randomly generated over 32 bits may lead to >>>> privacy >>>>and security concerns. >>>> >>>> The "may lead to security concerns" would be something that at the very >>>> least needs >>>> to be understood and specified in the Security Considerations section. >>>> If it is too >>>> difficult to determine the concerns, perhaps this optimization should >>>> be removed from >>>> the draft. >>>> >>> >>> >>>> >>>>As a result, the use of alternative designs requires careful >>>> security >>>>and privacy reviews. >>>> >>>> If it is known this proposal requires careful security reviews, were >>>> these done? If >>>> so, why not replace this warning
Re: [IPsec] IETF114 scheduling
Hi, If time permits, I would be happy to present: * IKEv2 Downstream Fragmentation Notification Extension and * IKEv2 Count Based SA Extension Yours, Daniel On Tue, Jun 28, 2022, 07:15 Robert Moskowitz wrote: > Right now, ipsecme is slotted together with tls. > > I guess they assume no overlap of interest? :) > > I do have interest in both, provided there is discussion of diet-esp at > 114. > > I do have commitments working with the FAA on their TLS extension. > > Bob > > ___ > 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] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
Yes, that what I then realized while reading the first email. At that point a document is needed wich could be pretty straight forward I believe. Yours, Daniel On Tue, Jun 7, 2022 at 8:50 AM Robert Moskowitz wrote: > > > On 6/7/22 08:43, Daniel Migault wrote: > > > > On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz > wrote: > >> Daniel, >> >> Back at it, now that ASTM is behind me... >> >> what will it take to bring this in line with SCHC. I don't know SCHC >> well enough to pick up the differences. >> >> We are basically balancing re-using a framework used / standardized by > the IETF versus defining our own framework. So it is just to remain more > aligned or coherent with what the IETF does. > > >> What will it take to add AES-GCM-12 to supported ciphers by IKE (and >> thus ESP)? For my use case, I have a hard time seeing why I need a >> 16-byte ICV. Even an 30 min operation with streaming video is a limited >> number of packets. I am going to talk to my contact at DJI to see what >> information they are willing to share... >> > > I think we do not enable compression of the signature as the security > implications are too hard to catch. When an reduced ICV is needed, there is > a need to define the transform. In your case rfc4106 seems to address your > concern with a 12 and even 8 byte ICV. > > > I was not clear. A 8750 IIV-AES-GCM-12 cipher... > > > > > > >> >> Bob >> >> On 5/16/22 16:47, Robert Moskowitz wrote: >> > Thanks, Daniel for the update. >> > >> > Now some comments. >> > >> > The necessary state is held within the IPsec Security Association >> and >> > >> >The document specifies the necessary parameters of the EHC Context to >> >allow compression of ESP and the most common included protocols, such >> >as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. >> > >> > Should any reference be made to cipher compression? At least >> > reference to 8750? Or since this is just the abs >> > >> >It also >> >defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per >> >packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent >> >over a single TCP or UDP session. >> > >> > >> > In UDP transport I am reducing 18 bytes (assuming cipher with zero >> > padding) to 4 bytes. Also worth noting here... >> > >> > >> >On the other hand, in IoT >> >communications, sending extra bytes can significantly impact the >> >battery life of devices and thus the life time of the device. The >> >document describes a framework that optimizes the networking overhead >> >associated to IPsec/ESP for these devices. >> > >> > >> > You say nothing about constrained comm links. This compression may >> > make ESP viable over links like LoRaWAN. >> > >> >ESP Header Compression (EHC) chooses another form of context >> >agreement, which is similar to the one defined by Static Context >> >Header Compression (SCHC). >> > >> > Reference rfc 8724. >> > >> > And more than 'similar"? Maybe "based on the one"? >> > >> >The context >> >itself can be negotiated during the key agreement, which allows only >> >minimal the changes to the actual ESP implementation. >> > >> > I don't get this. What only allows minimal changes? The key >> > agreement protocol or ECH? If the later then perhaps: >> > >> >The context >> >itself can be negotiated during the key agreement, which then needs >> > only >> >minimal the changes to the actual ESP implementation. >> > >> > More for introduction: >> > >> > Perhaps you can add that in transport mode, an SA may be for a single >> > transport/port to tune the ECH for that use and that multiple SAs >> > could be negotiated for this case. >> > >> > Question: Can a single IKE exchange produce multiple SAs? >> > >> > Here is my use case: >> > >> > Between the UA and GCS are two flows. One for Command and Control >> > (C2) the other streaming video. Both over UDP, but different ports. >> > So instead of having carry the UDP ports in all the messages, >> > negotiate separate SAs with the appropriate ECH. >> > >> > Ah, I see this in Sec 5. You should say some
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
On Mon, May 16, 2022 at 4:47 PM Robert Moskowitz wrote: > Thanks, Daniel for the update. > > Now some comments. > > The necessary state is held within the IPsec Security Association and > > The document specifies the necessary parameters of the EHC Context to > allow compression of ESP and the most common included protocols, such > as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. > > Should any reference be made to cipher compression? At least reference > to 8750? Or since this is just the abs > sure we can, but the transform itself is a bit outside EHC. > > It also > defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per > packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent > over a single TCP or UDP session. > > > In UDP transport I am reducing 18 bytes (assuming cipher with zero > padding) to 4 bytes. Also worth noting here... > > we are saying up to which likely corresponds to an extreme case and something like 18 bytes seems reasonable. > > On the other hand, in IoT > communications, sending extra bytes can significantly impact the > battery life of devices and thus the life time of the device. The > document describes a framework that optimizes the networking overhead > associated to IPsec/ESP for these devices. > > > You say nothing about constrained comm links. This compression may make > ESP viable over links like LoRaWAN. > > yes. if that is not in the doc, it might be we said it too many times that we finally forgot ;-). > ESP Header Compression (EHC) chooses another form of context > agreement, which is similar to the one defined by Static Context > Header Compression (SCHC). > > Reference rfc 8724. > > And more than 'similar"? Maybe "based on the one"? > > currently not, but this is actually what we think we should do. > The context > itself can be negotiated during the key agreement, which allows only > minimal the changes to the actual ESP implementation. > > I don't get this. What only allows minimal changes? The key agreement > protocol or ECH? If the later then perhaps: > > no. whatever is used to describe the compression descripression will not be implemented by setting a compressor / decompressor for at least ESP software implementation. The changes are minor. On the other hand, things may be a bit more complex for hardware based ESP which cannot be modified. In that case, we probably need to implement the compression / decompression steps outside ESP. > The context > itself can be negotiated during the key agreement, which then needs > only > minimal the changes to the actual ESP implementation. > > More for introduction: > > Perhaps you can add that in transport mode, an SA may be for a single > transport/port to tune the ECH for that use and that multiple SAs could > be negotiated for this case. > > Question: Can a single IKE exchange produce multiple SAs? > > The context is per SA, so I suppos ethe suggestion is to make it per SA if that has not been clearly specified in the IKE extension document. > Here is my use case: > > Between the UA and GCS are two flows. One for Command and Control (C2) > the other streaming video. Both over UDP, but different ports. So > instead of having carry the UDP ports in all the messages, negotiate > separate SAs with the appropriate ECH. > > Ah, I see this in Sec 5. You should say something about this in the intro. > > sec 4. > > EHC is able to compress any protocol encapsulated in ESP and ESP > itself. > > No really true per other claims. Does it offer compressing RTP? I need > that, probably, for my streaming video app. > > We probably need to clarify this. It seems the baseline is pretty much any layer related to traffic selectors, which I think could theoretically be pretty high up in the layers though in practice this may be reduced to IP and transport. > to compress any IP and transport protocol... > > And only TCP and UDP are shown, what about, say, SCTP? > > BTW, I note that you use 'IKEv2'. At this point is that really needed? > Should just IKE be enough? Has not IKEv1 been depreicated? > could be. > > 6. EHC Context > > > The EHC Context is defined on a per-SA basis. A context can be > defined for any protocol encapsulated with ESP and for ESP itself. > > Should that be "any IP or Transport protocol"? To exclude layer 5 > protocols (CoAP, RTP,,,)? > > probably > Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID > included... > > I tend to agree. > Or mayb
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
efined for any protocol encapsulated with ESP and for ESP itself. > > > > Should that be "any IP or Transport protocol"? To exclude layer 5 > > protocols (CoAP, RTP,,,)? > > > > Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID > > included... > > > > Or maybe 'typically'? As some layer 5 might be easy? RTP maybe? > > > > So this is it for this round of comments. I am looking at Appdx A and > > making a UDP example. Including IIV. > > > > Bob > > > > ___ > > 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] diet-esp - How do you know?
On Wed, May 25, 2022 at 8:15 AM Robert Moskowitz wrote: > > > On 5/24/22 17:26, Daniel Migault wrote: > > The IKE negotiation is for diet-esp is currently defined in a specific > draft: > > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/ > > > I totally missed this draft. It should at least be referenced in > ipsecme-diet-esp. > Sure. > > I will have to go read it to see if it covers my concerns. > > > I think you are suggesting that the architecture description details what > is negotiated by IKEv2. Am I correct ? > > > This is an arch doc? Does not read like one! I was thinking about > explicit sections on IKE processes. But now that I know that there is an > IKE draft, at least referencing it in the intro should cover things. > Maybe. ;) > > By arch, I meant the description of where in the stack compression/decompresison occurs. This is summarized in section 4 currently. > > Yours, > Daniel > > On Tue, May 24, 2022 at 4:59 PM Robert Moskowitz > wrote: > >> In My Highly Biased Opinion,,, >> >> There should be a section on the IKE negotiation of diet-esp, >> specifically calling out how this is done. Especially the incoming SPI >> selection. >> >> Then there should be a section, perhaps sub-section of above, on incoming >> datagram processing to recognize a shortened SPI on the wire and pass it >> off to diet-esp processing. >> >> I keep thinking back to when we had fun writing 2410 and one implementor >> did not get the joke and did it wrong and would not interop in null mode >> with any other product. >> >> They were really not happy campers... >> >> On 5/24/22 16:47, Daniel Migault wrote: >> >> The issue only comes when a gateway wants to support all sizes of SPIs 0 >> - 1 - 2 - 3 - 4 bytes - which is very unlikely. For a deterministic lookup, >> I would suggest using IP addresses and the minimum allowed byted compressed >> SPI. >> If you use 2 - 3 bytes, the likelihood of collision might still be very >> low to support an additional signature check. >> >> Yours, >> Daniel >> >> On Tue, May 24, 2022 at 4:30 PM Robert Moskowitz >> wrote: >> >>> That is the 'easy' part. >>> >>> What does the code do when it receives an ESP packet? How do it know >>> that it is a diet-esp packet and apply the rules? >>> >>> Next Header just says: ESP. >>> >>> On 5/24/22 16:23, Daniel Migault wrote: >>> >>> This is correct. IKEv2 is used both to agree on the use of Diet-ESP as >>> well as values to be used for the compression/decompression. >>> >>> Yours, >>> Daniel >>> >>> On Tue, May 24, 2022 at 11:14 AM Paul Wouters >> 40aiven...@dmarc.ietf.org> wrote: >>> >>>> >>>> On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz < >>>> rgm-...@htt-consult.com> wrote: >>>> >>>>> I think there is something else I am missing here. >>>>> >>>>> How does the receiving system 'know' that the packet is a diet-esp >>>>> packet? >>>>> >>>> >>>> >>>> https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 >>>> >>>> It's negotiated with IKEv2. >>>> >>>> I guess the IKE stack has to signal this to the ESP implementation on >>>> what to expect when >>>> the policy is installed ? >>>> >>>> Paul >>>> >>>> ___ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>> >>> >>> -- >>> Daniel Migault >>> Ericsson >>> >>> ___ >>> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >> >> -- >> Daniel Migault >> Ericsson >> >> ___ >> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec >> >> >> > > -- > Daniel Migault > Ericsson > > ___ > IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec > > > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] diet-esp - How do you know?
The IKE negotiation is for diet-esp is currently defined in a specific draft: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/ I think you are suggesting that the architecture description details what is negotiated by IKEv2. Am I correct ? Yours, Daniel On Tue, May 24, 2022 at 4:59 PM Robert Moskowitz wrote: > In My Highly Biased Opinion,,, > > There should be a section on the IKE negotiation of diet-esp, specifically > calling out how this is done. Especially the incoming SPI selection. > > Then there should be a section, perhaps sub-section of above, on incoming > datagram processing to recognize a shortened SPI on the wire and pass it > off to diet-esp processing. > > I keep thinking back to when we had fun writing 2410 and one implementor > did not get the joke and did it wrong and would not interop in null mode > with any other product. > > They were really not happy campers... > > On 5/24/22 16:47, Daniel Migault wrote: > > The issue only comes when a gateway wants to support all sizes of SPIs 0 - > 1 - 2 - 3 - 4 bytes - which is very unlikely. For a deterministic lookup, I > would suggest using IP addresses and the minimum allowed byted compressed > SPI. > If you use 2 - 3 bytes, the likelihood of collision might still be very > low to support an additional signature check. > > Yours, > Daniel > > On Tue, May 24, 2022 at 4:30 PM Robert Moskowitz > wrote: > >> That is the 'easy' part. >> >> What does the code do when it receives an ESP packet? How do it know >> that it is a diet-esp packet and apply the rules? >> >> Next Header just says: ESP. >> >> On 5/24/22 16:23, Daniel Migault wrote: >> >> This is correct. IKEv2 is used both to agree on the use of Diet-ESP as >> well as values to be used for the compression/decompression. >> >> Yours, >> Daniel >> >> On Tue, May 24, 2022 at 11:14 AM Paul Wouters > 40aiven...@dmarc.ietf.org> wrote: >> >>> >>> On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz < >>> rgm-...@htt-consult.com> wrote: >>> >>>> I think there is something else I am missing here. >>>> >>>> How does the receiving system 'know' that the packet is a diet-esp >>>> packet? >>>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 >>> >>> It's negotiated with IKEv2. >>> >>> I guess the IKE stack has to signal this to the ESP implementation on >>> what to expect when >>> the policy is installed ? >>> >>> Paul >>> >>> ___ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> >> -- >> Daniel Migault >> Ericsson >> >> ___ >> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec >> >> >> > > -- > Daniel Migault > Ericsson > > ___ > IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec > > > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] diet-esp - How do you know?
I agree, maybe we should be more explicit in the security consideration. I think at the time we wrote it, we did not want to define a SPI format and leave it to the implementer. But I agree mentioning it as an example would be clarifying. An example where a 0 byte SPI could be used is when the pairing is performed by lower layers - like a remote garage door. Yours, Daniel On Tue, May 24, 2022 at 4:56 PM Scott Fluhrer (sfluhrer) wrote: > The easiest way would be to assign the first few bits of the SPI to > indicate the SPI size; for example, all 8 bit SPIs might be allocated to > have the first two bits being 11; all 16 bit SPIs might have those two bits > being 10; etc. That way, an examination of the first few bits of the SPI > would unambiguously give you the SPI size. > > > > Obviously, this doesn’t apply to a ‘0 byte SPI’. I have no idea how that > is intended to be processed; does that mean that the decrypter is expected > to just try to decrypt the packet with all the SAs he has and see which one > worked? > > > > *From:* IPsec *On Behalf Of *Daniel Migault > *Sent:* Tuesday, May 24, 2022 4:48 PM > *To:* Robert Moskowitz > *Cc:* Paul Wouters ; IPsecME WG < > ipsec@ietf.org> > *Subject:* Re: [IPsec] diet-esp - How do you know? > > > > The issue only comes when a gateway wants to support all sizes of SPIs 0 - > 1 - 2 - 3 - 4 bytes - which is very unlikely. For a deterministic lookup, I > would suggest using IP addresses and the minimum allowed byted compressed > SPI. > > If you use 2 - 3 bytes, the likelihood of collision might still be very > low to support an additional signature check. > > > > Yours, > > Daniel > > > > On Tue, May 24, 2022 at 4:30 PM Robert Moskowitz > wrote: > > That is the 'easy' part. > > What does the code do when it receives an ESP packet? How do it know that > it is a diet-esp packet and apply the rules? > > Next Header just says: ESP. > > On 5/24/22 16:23, Daniel Migault wrote: > > This is correct. IKEv2 is used both to agree on the use of Diet-ESP as > well as values to be used for the compression/decompression. > > > > Yours, > Daniel > > > > On Tue, May 24, 2022 at 11:14 AM Paul Wouters 40aiven...@dmarc.ietf.org> wrote: > > > > On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz > wrote: > > I think there is something else I am missing here. > > How does the receiving system 'know' that the packet is a diet-esp packet? > > > > > https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 > > > > It's negotiated with IKEv2. > > > > I guess the IKE stack has to signal this to the ESP implementation on what > to expect when > > the policy is installed ? > > > > Paul > > > > ___ > 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 > > > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] diet-esp - How do you know?
The issue only comes when a gateway wants to support all sizes of SPIs 0 - 1 - 2 - 3 - 4 bytes - which is very unlikely. For a deterministic lookup, I would suggest using IP addresses and the minimum allowed byted compressed SPI. If you use 2 - 3 bytes, the likelihood of collision might still be very low to support an additional signature check. Yours, Daniel On Tue, May 24, 2022 at 4:30 PM Robert Moskowitz wrote: > That is the 'easy' part. > > What does the code do when it receives an ESP packet? How do it know that > it is a diet-esp packet and apply the rules? > > Next Header just says: ESP. > > On 5/24/22 16:23, Daniel Migault wrote: > > This is correct. IKEv2 is used both to agree on the use of Diet-ESP as > well as values to be used for the compression/decompression. > > Yours, > Daniel > > On Tue, May 24, 2022 at 11:14 AM Paul Wouters 40aiven...@dmarc.ietf.org> wrote: > >> >> On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz >> wrote: >> >>> I think there is something else I am missing here. >>> >>> How does the receiving system 'know' that the packet is a diet-esp >>> packet? >>> >> >> >> https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 >> >> It's negotiated with IKEv2. >> >> I guess the IKE stack has to signal this to the ESP implementation on >> what to expect when >> the policy is installed ? >> >> Paul >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > -- > Daniel Migault > Ericsson > > ___ > IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec > > > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] diet-esp - How do you know?
This is correct. There is currently some text in the security consideration but we can re-emphasize this of course. This however does not seem to me a huge issue as inbound SPI are selected by the peer using these inbound SPI. Note also that a full SPI value is agreed with IKE, diet-esp only performs the compression / decompression. Yours, Daniel On Tue, May 24, 2022 at 12:14 PM Robert Moskowitz wrote: > Scott, > > That is my question/point. And if I understand diet-esp and lsb, then the > 8-bit SPI maps to the full SPI in the SA is xx07? > > Ah, the *Receiver* picks the incoming SPIs. It has been so many years > since I looked into the protocol/code that I lost sight of this. I had it > reversed. Thus the receiver MUST be careful in selecting its incoming SPIs > such that there is no collision. > > The draft needs to spell this out. > > And for a UAS Network Remote ID Service Provider, it would use a 2-byte > transmitted SPI to allow for a reasonable number of UAS in service at any > time... > > On 5/24/22 11:30, Scott Fluhrer (sfluhrer) wrote: > > I believe that the question is “when someone receives an IPsec packet, how > do they determine the SA, assuming that they have negotiated both standard > SAs (with 32 bit SPIs), and diet-esp (with shorter SPIs).” > > > > My initial assumption was that, as the receiver picks its incoming SPIs, > that they pick them to allow unambiguous lookup. For example, if a > diet-esp inbound SA has an 8 bit SPI of 07, that means that the > implementation ensures that it does not have any standard inbound SAs with > SPIs of the form 07. > > > > It might not be totally unreasonable if the diet draft spelled out a > method for achieving this… > > > > *From:* IPsec *On > Behalf Of *Paul Wouters > *Sent:* Tuesday, May 24, 2022 11:14 AM > *To:* Robert Moskowitz > *Cc:* IPsecME WG > *Subject:* Re: [IPsec] diet-esp - How do you know? > > > > > > On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz > wrote: > > I think there is something else I am missing here. > > How does the receiving system 'know' that the packet is a diet-esp packet? > > > > > https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 > > > > It's negotiated with IKEv2. > > > > I guess the IKE stack has to signal this to the ESP implementation on what > to expect when > > the policy is installed ? > > > > Paul > > > > _______ > IPsec mailing listIPsec@ietf.orghttps://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] diet-esp - How do you know?
This is correct. IKEv2 is used both to agree on the use of Diet-ESP as well as values to be used for the compression/decompression. Yours, Daniel On Tue, May 24, 2022 at 11:14 AM Paul Wouters wrote: > > On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz > wrote: > >> I think there is something else I am missing here. >> >> How does the receiving system 'know' that the packet is a diet-esp packet? >> > > > https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 > > It's negotiated with IKEv2. > > I guess the IKE stack has to signal this to the ESP implementation on what > to expect when > the policy is installed ? > > Paul > > ___ > 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] Fw: New Version Notification for draft-mglt-ipsecme-ikev2-diet-esp-extension-02.txt
Hi, Here is the description of the IKE payload to negotiate Diet-ESP. There is probably some discussion to understand if one need to extend it to include some SCHC profiles for example. I am happy to get any feed back regarding this aspect. I also think the document is ready for adoption and that changes can be made once adopted. Yours, Daniel From: internet-dra...@ietf.org Sent: Friday, May 13, 2022 1:24 PM To: Daniel Migault; David Schinazi; Tobias Guggemos Subject: New Version Notification for draft-mglt-ipsecme-ikev2-diet-esp-extension-02.txt A new version of I-D, draft-mglt-ipsecme-ikev2-diet-esp-extension-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-ikev2-diet-esp-extension Revision: 02 Title: Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) Strategy Document date: 2022-05-13 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-ikev2-diet-esp-extension-02.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-ikev2-diet-esp-extension-02 Abstract: ESP Header Compression (EHC) reduces the ESP overhead by compressing ESP fields. Compression results from a coordination of various EHC Rules designed as EHC Strategies. An EHC Strategy may require to be configured with some configuration parameters. When a Security Association (SA) is enabling EHC, the two peers need to agree which EHC Strategy is applied as well as its associated configuration parameters. This document describes an extension of IKEv2 that enables two peers to agree on a specific EHC Strategy as well as its associated configuration parameters. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-mglt-ipsecme-diet-esp-08.txt
Hi, Please find the document describing Diet-ESP. The compression mechanism is not being described using SCHC. We initially thought of updating the document with SCHC and so wait for SCHC to be published. On the other hand this is not mandatory and we would like to understand if the WG has an opinion. In any case, i believe the document is sufficiently advanced to get adopted. Yours, Daniel From: internet-dra...@ietf.org Sent: Friday, May 13, 2022 12:29 PM To: Carsten Bormann; Daniel Migault; David Schinazi; Tobias Guggemos Subject: New Version Notification for draft-mglt-ipsecme-diet-esp-08.txt A new version of I-D, draft-mglt-ipsecme-diet-esp-08.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-diet-esp Revision: 08 Title: ESP Header Compression and Diet-ESP Document date: 2022-05-13 Group: Individual Submission Pages: 53 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-diet-esp-08.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-diet-esp-08 Abstract: With the use of encrypted ESP for secure IP communication, the compression of IP payload is only possible with complex frameworks, such as RObust Header Compression (ROHC). Such frameworks are too complex for numerous use cases and especially for IoT scenarios, which makes IPsec not being used here, although it offers architectural benefits. ESP Header Compression (EHC) defines a flexible framework to compress communications protected with IPsec/ESP. Compression and decompression is defined by EHC Rules orchestrated by EHC Strategies. The necessary state is hold within the IPsec Security Association and can be negotiated during key agreement, e.g. with IKEv2. The document specifies the necessary parameters of the EHC Context to allow compression of ESP and the most common included protocols, such as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. It also defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent over a single TCP or UDP session. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-02.txt
Hi, Please find an updated version of our document to handle packet fragmentation over an IPv4 network. We believe we have considered all comments received so far and we would like our document to be adopted as WG document. Yours, Daniel From: internet-dra...@ietf.org Sent: Friday, May 13, 2022 12:24 PM To: Congjie Zhang; Harold Liu; Daniel Migault; Renwang Liu Subject: New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-02.txt A new version of I-D, draft-liu-ipsecme-ikev2-mtu-dect-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-liu-ipsecme-ikev2-mtu-dect Revision: 02 Title: IKEv2 IPv4 Downstream Fragmentation Notification Extension Document date: 2022-05-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-liu-ipsecme-ikev2-mtu-dect-02.txt Status: https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/ Htmlized: https://datatracker.ietf.org/doc/html/draft-liu-ipsecme-ikev2-mtu-dect Diff: https://www.ietf.org/rfcdiff?url2=draft-liu-ipsecme-ikev2-mtu-dect-02 Abstract: This document defines the IKEv2 IPv4 Downstream Fragmentation Notification Extension which enables a receiving security gateway to notify the sending receiving gateway that downstream fragmentation is ongoing. The sending gateway MAY take action to avoid such fragmentation to occur. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fw: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-01.txt
Hi, Please find an updated version of our draft describing how optimising the use of count based SA. We would like the document to be adopted as a WG document. Yours, Daniel From: internet-dra...@ietf.org Sent: Friday, May 13, 2022 12:18 PM To: Congjie Zhang; Harold Liu; Daniel Migault Subject: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-01.txt A new version of I-D, draft-liu-ipsecme-ikev2-rekey-redundant-sas-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-liu-ipsecme-ikev2-rekey-redundant-sas Revision: 01 Title: IKEv2 Count Based SA Extension Document date: 2022-05-13 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-liu-ipsecme-ikev2-rekey-redundant-sas-01.txt Status: https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-rekey-redundant-sas/ Htmlized: https://datatracker.ietf.org/doc/html/draft-liu-ipsecme-ikev2-rekey-redundant-sas Diff: https://www.ietf.org/rfcdiff?url2=draft-liu-ipsecme-ikev2-rekey-redundant-sas-01 Abstract: This document describes an IKEv2 extension that enables a more rational use of count based SA. This includes preventing the creation of redundant SAs resulting from simultaneous rekeys. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] More comments on draft-mglt-ipsecme-diet-esp-07
On Wed, May 11, 2022 at 4:48 PM Robert Moskowitz wrote: > Continuing at sec 6.1: > > Skipping 6.2 for now, as it will not be used for current use case (I > realize I may have one for Manned Aircraft). > > Good til 7.2, then skipping 7.2 and 7.3 for now. > > I like 7.4 in that UDP gets compressed to zero bytes. And the way you > have constructed diet-esp to include transport, a separate SCHC rule for > transport is not needed. Now if the payload is CoAP, then things will > be different. Per the rfc 8824. > > Skip 7.5 and 7.6 > > Sec 11: > > Security Parameter Index (SPI): >Until Diet-ESP is not deployed outside the scope of IoT and small >devices, > > > r/ not / / > > changed > ? > > What is that not doing there? > > Sequence Number (SN): If incremented for each ESP packet, the SN may >leak some information like the amount of transmitted data or the >age of the sensor. > > If 2 bytes of SN are sent using a counter, there is little to no leakage > of sensor age. > > If little traffic from sensor then only 1 byte may be better for this > purpose. > > I just don't see this as a risk if care is taken. You may want to say > this. > > I added a sentence in the security consideration. Thanks for the suggestion. > Finally where is the open source code available? > > You need a UDP app in transport mode example in App 1. :) > > If you get this draft active, I will work on providing that example. ;) > > sure, I will publish an updated version very soon. > > thanks. > > ___ > 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] Comments on draft-mglt-ipsecme-diet-esp-07
I applied your comments on my local copy. Please see some additional comments inline. Yours, Daniel On Thu, May 12, 2022 at 12:30 PM Robert Moskowitz wrote: > > > On 5/12/22 11:58, Daniel Migault wrote: > > Hi Bob, > > I apologize for the delayed response. I am happy to go back to this > document. > > > Good and thank you. > > I also see a tunnel application, but that will be for later. > > First UDP Transport and UDP BEET mode. > > I checked previous versions and did not find a UDP Transport mode example. The current version is limited to UDP in tunnel mode. I do not expect much changes, but that is something we can add. I also believe that BEET mode - though no a standard might be good but that one I am pretty sure I never drafted it. > > Yours, > Daniel > > On Fri, May 6, 2022 at 5:02 PM Robert Moskowitz > wrote: > >> First read-through. >> >> Is there an implementation of this draft? >> >> yes we do have an implementation on contiki, as well as in python. > > The implementation is available here: > https://bitbucket.org/sylvain_www/diet-esp-contiki > > You can also find a description of the implementation as well as some > experimental measurements we performed there: > > https://www.researchgate.net/publication/316348221_Diet-ESP_IP_layer_security_for_IoT > > Obviously it being last published in '19 some drafts are now RFCs and >> thus need updating. >> >> Sure ;-) > >> Page 5 at top: >> >> Non ESP fields may be compressed by ESP under >> certain circumstances, but EHC is not intended to provide a generic >> way outside of ESP to compress these protocols. >> >> How does EHC work with SCHC CoAP compression, rfc 8824? I would think >> this is a must work with... >> >> I agree that is something we should consider and probably clarify. > Diet-ESP is not intended to provide some compression beyond what is being > used for TS. I do not see CoAP as part of these TS, and as such, I would > expect the compression associated to CoAP to be handled "after Diet-ESP". > Not having read how SCHC compresses CoAP, I Assume that SCHC CoAP > compresses also the UDP/IP part which ends in the compressed CoAP packet > not being an IP packet. On the sender side, when IPsec is applied to such > packet, there is a need that this compressed CoAP packet matches the SPD TS > - unless these are set to ANY. So my first question would be how SCHC > CoAP works with IPsec ? > > > Most of the SCHC CoAP rfc deals with the CoAP headers, and any UDP > consideration is out-of-scope. Even with UDP/DTLS, 8824 is silent. I > think. > > So this draft can easily ignore CoAP. It took me a bit of reading to get > to this point.. > > > Assuming the compressed packet is protected by IPsec, only the ESP fields > will be subject to compression. On the other hand, if IPsec requires some > fields, there is probably a need to request Diet-ESP to compress what > SCHC(CoAP) has not compressed to make IPsec work. > > > As far as diet-esp is concerned any 8824 CoAP compression is just data > payload. The SCHC RuleID is the first field either in the UDP data or the > DTLS data. > > > > > >> As depicted in Figure 1, the EHC Strategy - Diet-ESP in our case - >> and the EHC Context are agreed upon between the two peers, e.g. >> during key exchange. The EHC Rules are to be implemented on the >> peers and do not require further agreement. >> >> Can the EHC Strategy, Context, and Rules be static between two hosts? >> This is of interest to me with Network Remote ID where these will always >> be the same (I think so far) between the UA and Service Provider. >> >> In fact if aligned with SCHC, static is the norm which can be overridden >> during a key exchange. This approach would allow the key exchange to be >> unmodified to support diet-esp. >> >> Rules are static and require only to agree on a very small number of > parameters via IKEv2. What I do not think we considered is the exchange of > additional SCHC rules. > > > I just asked this again in my latest missive. I think you need the IKE > payloads. > yes, I am wondering if adding some SCHC IDs would be sufficient or if something more would be needed. > > And I will somewhere have to do the matching HIP payloads. ;) > > > >> With EHC, the agreement of the level or occurrence of compression is >> left the negotiation protocol (e.g. IKEv2), contradicting the >> signalization of the level of compression for a certain packet send >> over the wire. >> >> This is a sent
Re: [IPsec] Comments on draft-mglt-ipsecme-diet-esp-07
Hi Bob, I apologize for the delayed response. I am happy to go back to this document. Yours, Daniel On Fri, May 6, 2022 at 5:02 PM Robert Moskowitz wrote: > First read-through. > > Is there an implementation of this draft? > > yes we do have an implementation on contiki, as well as in python. The implementation is available here: https://bitbucket.org/sylvain_www/diet-esp-contiki You can also find a description of the implementation as well as some experimental measurements we performed there: https://www.researchgate.net/publication/316348221_Diet-ESP_IP_layer_security_for_IoT Obviously it being last published in '19 some drafts are now RFCs and > thus need updating. > > Sure ;-) > Page 5 at top: > > Non ESP fields may be compressed by ESP under > certain circumstances, but EHC is not intended to provide a generic > way outside of ESP to compress these protocols. > > How does EHC work with SCHC CoAP compression, rfc 8824? I would think > this is a must work with... > > I agree that is something we should consider and probably clarify. Diet-ESP is not intended to provide some compression beyond what is being used for TS. I do not see CoAP as part of these TS, and as such, I would expect the compression associated to CoAP to be handled "after Diet-ESP". Not having read how SCHC compresses CoAP, I Assume that SCHC CoAP compresses also the UDP/IP part which ends in the compressed CoAP packet not being an IP packet. On the sender side, when IPsec is applied to such packet, there is a need that this compressed CoAP packet matches the SPD TS - unless these are set to ANY. So my first question would be how SCHC CoAP works with IPsec ? Assuming the compressed packet is protected by IPsec, only the ESP fields will be subject to compression. On the other hand, if IPsec requires some fields, there is probably a need to request Diet-ESP to compress what SCHC(CoAP) has not compressed to make IPsec work. > As depicted in Figure 1, the EHC Strategy - Diet-ESP in our case - > and the EHC Context are agreed upon between the two peers, e.g. > during key exchange. The EHC Rules are to be implemented on the > peers and do not require further agreement. > > Can the EHC Strategy, Context, and Rules be static between two hosts? > This is of interest to me with Network Remote ID where these will always > be the same (I think so far) between the UA and Service Provider. > > In fact if aligned with SCHC, static is the norm which can be overridden > during a key exchange. This approach would allow the key exchange to be > unmodified to support diet-esp. > > Rules are static and require only to agree on a very small number of parameters via IKEv2. WHat I do not think we considered is the exchange of additional SCHC rules. > With EHC, the agreement of the level or occurrence of compression is > left the negotiation protocol (e.g. IKEv2), contradicting the > signalization of the level of compression for a certain packet send > over the wire. > > This is a sentence fragment and I don't get what is being said here. > Taking out the comma delimited: > > With EHC, contradicting the > signalization of the level of compression for a certain packet send > over the wire. > > ? > > Good I will need to review the doc. > This > leads to multiple SAs, and thus, multiple SPIs for different levels > of compression agreed with the EHC Context. > > This can lead to multiple... > > Sure, Thanks. > I think > > If the sender detects the de-compression can not be guaranteed with a > given EHC Context and EHC Strategy, it MUST NOT apply compression. > > If the sender detects that the de- > > ? > > Made it through sec 6, stopping for now a 6.1 where I will continue Monday? > > I see that with ESP Next Header compression and ony UDP in the SA, that > SCHC for UDP is not needed so don't need an IP Protocol number for SCHC > here. But what about SCHC for CoAP over UDP? > > I think there is a need to define which layers will compress the inner UDP, and this is likely to depend on the TS values. > Anyway, stopping for now. More, I suspect, later. > > Oh, and NIST is having their 4th LWC workshop M-W, so I am busy with > that too! > > Bob > > ___ > 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] Transport ESP and SCHC
minimal esp describes how to implement a standard ESP in a constrained
environment with minimal options as well as variants to minimize the impact
of the implementation on the device.
diet-esp defines how to compress / decompress ESP. The description is
pretty much complete. We implemented it on Contiki. We were wondering
whether to adapt with SCHC. It would be cleaner in my opinion, but that is
just a thought.
Yours,
Daniel
On Tue, May 3, 2022 at 4:44 PM Robert Moskowitz
wrote:
> Daniel and Tero,
>
> How do diet-esp and minimal-esp intersect?
>
> minimal-esp is, it seems ready for publication, so nothing really changing
> it is possible.
>
> But what does diet-esp do instead?
>
> Squeezing down esp and adding support for SCHC ('easy' by adding it as an
> IP Protocol) is of interest to me...
>
> Bob
>
> On 4/21/22 10:36, Daniel Migault wrote:
>
> The question we are asking ourselves is should we re-write the spec with
> SCHC.
>
> Yours,
> Daniel
>
> On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote:
>
>> Robert Moskowitz writes:
>> > Yet in 8724, they define a in-band header:
>> >
>> >|--- Compressed Header ---|
>> >
>> >+-++
>> >
>> >| RuleID | Compression Residue | Payload |
>> >
>> >+-++
>> >
>> > How do you include this? This is especially needed with CoAP, rfc
>> 8824.
>> >
>> > What is preconfigured is what does the RuleID instruct you to do
>> with that
>> > compression residue.
>> >
>> > A bit more on this. When above Transport as in 8824, the port number
>> needs to
>> > know how to process the RuleID. When below IP as in 9011, the MAC
>> needs a
>> > type assigned for SCHC to know to use the RuleID for IP/whatever
>> expansion.
>> > MAC types are not the IETF's problem.
>> >
>> > It takes something like ESP that sits below Transport, to change this.
>> Thus
>> > this COULD be an lpwan issue for introducing SCHC, or it could be an
>> ipsecme
>> > issue as as far as I can think, only ESP presents this issue.
>>
>> You might want to check the Diet ESP work that was done in the IPsecME
>> WG few years back. It mostly died because there was not enough
>> interest to work on the drafts or implementations.
>>
>> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/
>>
>> This is still in the IPsecME charter item so if there is interest to
>> start working on this then IPsecME WG has space for it:
>>
>> A growing number of use cases for constrained networks - but not
>> limited to those networks - have shown interest in reducing ESP
>> (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The
>> WG will define extensions of ESP and IKEv2 to enable ESP header
>> compression.
>>
>> Possible starting points are draft-mglt-ipsecme-diet-esp,
>> draft-mglt-ipsecme-ikev2-diet-esp-extension,
>> draft-smyslov-ipsecme-ikev2-compression and
>> draft-smyslov-ipsecme-ikev2-compact.
>> --
>> kivi...@iki.fi
>>
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>
> --
> Daniel Migault
> Ericsson
>
> ___
> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec
>
>
>
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)
Hi Paul, Please find my response to your comments. The current version of the file integrates the language changes as well as changes to address the concerns of this thread: https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/d7710c19802bdce4c978d71ad303b739e1406f1e Yours, Daniel On Tue, Apr 12, 2022 at 5:10 PM Paul Wouters wrote: > > On Tue, Apr 5, 2022 at 10:09 PM Daniel Migault > wrote: > >> Hi Paul, >> >> Thanks for commenting. Please find my responses below. >> >> Section 2: >> >>> >>> It suggests a partial SPI match can be used, based on the assumption that >>> the SPI number is known to have mostly zeros because the device only uses >>> a hardcoded limited set (eg 257 to 260). While this is true for the >>> outbound >>> SPI, this may not be true for the inbound SPI, especially if the peer is >>> not >>> a "minimal ESP" device but a regular multipurpose OS. I think some >>> clarification >>> is needed for this minimum implementation optimization. >>> >>> >> I probably missed the comment. I understand that a partial SPI match >> would mean that only a subset of bytes will be considered, but I cannot >> find text that suggests it. I do not also see any mention of special values >> for the SPI. I also understand from the comment that the text is suggesting >> some SPI values but I cannot find what text suggests it - at least for a >> very small subset. >> > > This was based on: > > The index may be based on > the full 32 bits of SPI or a subset of these bits. > > > If you index it on a partial length, you need to have generated these as well > with reduced length or else this operation would not provide unique indexes. > > And you are not generating the peer's SPI, so those indexes need to use the > full 32 bit too. > > Perhaps you mean to say that for indexing your own generated SPIs, you might > know you only need to look at a subset of bytes? > > Perhaps you can clarify the indexing sentence ? > > The SPI field (4 bytes) is decoupled between the SPI value (3 bytes) and a rekey index (1 byte). Here is the text that I believe addresses your concern: """ Alternatively, some constrained devices will not implement IKEv2 or Minimal IKEv2 and as such will not be able to manage a roll-over between two distinct SAs. In addition, some of these constrained devices are also likely to have a limited number of SAs - likely to be indexed over 3 bytes only for example. One possible way to enable a rekey mechanism with these devices is to use the SPI where for example the first 3 bytes designates the SA while the remaining byte indicates a rekey index. SPI numbers can be used to implement tracking the inbound SAs when rekeying is taking place. When rekeying a SPI, the new SPI could use the SPI bytes to indicate the rekeying index. """ > > >> [2] >>> >>> Section 2.1: >>> >>>SPI that are not randomly generated over 32 bits may lead to >>> privacy >>>and security concerns. >>> >>> The "may lead to security concerns" would be something that at the very >>> least needs >>> to be understood and specified in the Security Considerations section. >>> If it is too >>> difficult to determine the concerns, perhaps this optimization should be >>> removed from >>> the draft. >>> >> >> >>> >>>As a result, the use of alternative designs requires careful >>> security >>>and privacy reviews. >>> >>> If it is known this proposal requires careful security reviews, were >>> these done? If >>> so, why not replace this warning of danger with the actual output of >>> those reviews? >>> If reviews were not done, it would imply this document hasn't fully >>> worked out its >>> Security Considerations. >>> >> >> The concerns are explicitly mentioned in this section with what needs to >> be considered. >> > > This is mostly a language problem then. When a document states " the use > of alternative designs requires careful security and privacy reviews", > it implies the reader needs to do these themselves and these were not part > of the document. I had given some language improvement suggestions > separately that might cover this? If not, please clarify this issue. > > current text is: """ As a result, the use of alternative designs requires careful security and privacy reviews. """ > [3] >>> >
Re: [IPsec] Transport ESP and SCHC
The question we are asking ourselves is should we re-write the spec with SCHC. Yours, Daniel On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote: > Robert Moskowitz writes: > > Yet in 8724, they define a in-band header: > > > >|--- Compressed Header ---| > > > >+-++ > > > >| RuleID | Compression Residue | Payload | > > > >+-++ > > > > How do you include this? This is especially needed with CoAP, rfc > 8824. > > > > What is preconfigured is what does the RuleID instruct you to do > with that > > compression residue. > > > > A bit more on this. When above Transport as in 8824, the port number > needs to > > know how to process the RuleID. When below IP as in 9011, the MAC needs > a > > type assigned for SCHC to know to use the RuleID for IP/whatever > expansion. > > MAC types are not the IETF's problem. > > > > It takes something like ESP that sits below Transport, to change this. > Thus > > this COULD be an lpwan issue for introducing SCHC, or it could be an > ipsecme > > issue as as far as I can think, only ESP presents this issue. > > You might want to check the Diet ESP work that was done in the IPsecME > WG few years back. It mostly died because there was not enough > interest to work on the drafts or implementations. > > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/ > > This is still in the IPsecME charter item so if there is interest to > start working on this then IPsecME WG has space for it: > > A growing number of use cases for constrained networks - but not > limited to those networks - have shown interest in reducing ESP > (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The > WG will define extensions of ESP and IKEv2 to enable ESP header > compression. > > Possible starting points are draft-mglt-ipsecme-diet-esp, > draft-mglt-ipsecme-ikev2-diet-esp-extension, > draft-smyslov-ipsecme-ikev2-compression and > draft-smyslov-ipsecme-ikev2-compact. > -- > kivi...@iki.fi > > ___ > 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] [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-10.txt
Hi, Thanks Paul for the comments. Please find my response below: https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/3 The main question I have is regarding the use of normative language in an informational document. I would liek some guidance from the IESG so I can implement the changes. Yours, Daniel On Fri, Apr 8, 2022 at 3:21 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Light-Weight Implementation Guidance WG > of the IETF. > > Title : Minimal IP Encapsulating Security Payload (ESP) > Authors : Daniel Migault > Tobias Guggemos > Filename: draft-ietf-lwig-minimal-esp-10.txt > Pages : 15 > Date: 2022-04-08 > > Abstract: >This document describes the minimal properties IP Encapsulating >Security Payload (ESP) implementation needs to meet to remain >interoperable with the standard RFC4303 ESP. Such a minimal version >of ESP is not intended to become a replacement of the RFC 4303 ESP. >Instead, a minimal implementation is expected to be optimized for >constrained environment while remaining interoperable with >implementations of RFC 4303 ESP. In addition, this document also >provides some considerations to implement minimal ESP in a >constrained environment which includes limiting the number of flash >writes, handling frequent wakeup / sleep states, limiting wakeup >time, or reducing the use of random generation. > >This document does not update or modify RFC 4303, but provides a >compact description of how to implement the minimal version of the >protocol. RFC 4303 remains the authoritative description. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lwig-minimal-esp-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-minimal-esp-10 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______ > Lwip mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt
Hi Paul, That is correct and this is what we are doing with a 10% over each side when time base SA life time is used. The number I gave was measured using byte base SA life time. We tried the same approach for the byte base SA lifetime but the same strategy does not work -- unless we consider very high values up to 40% of the SA life time. In our case, the traffic is symmetric, that is the same amount of bytes is carried into both directions, SA life times are randomized +/- 10% and each gateway checks the SA used for decryption. Such randomization (or difference between the SAs) is not sufficient as that the counter is checked approximately every 2 s to determine if a rekey needs to be performed and any traffic burst cancels differences introduced by the randomization. In our current configuration initiator and responder are really interchangeable, and this mostly results from the fact that they look at different SAs AND that the traffic is relatively symmetric. The ability to agree which of the peers is handling the rekey is expected to prevent such simultaneous rekey as the behavior becomes predictable between two peers and between different implementations. There is still a need to introduce some randomness to prevent multiple rekeys to happen at the same time. Assigning a rekey responsibility requires one peer to look at both (unidirectional SAs) as opposed to one, but over the number of SA the necessary resource associated to this responsibility will remain the same as the one considered. What we need to make sure is that a rekey occurs even if the peer designated to rekey does not fulfill its commitment. If we extend the case to traffic that is asymmetric (with our implementation) the asymmetry of the traffic competes with the difference of the SA lifetime which results for a given SA in randomness increasing or decreasing the probability of simultaneous rekey. So here also, we believe that being able to specify a behavior will prevent or at least limit the simultaneous rekey. Yours, Daniel On Tue, Nov 30, 2021 at 2:42 PM Paul Wouters wrote: > > On Tue, Nov 30, 2021 at 8:21 AM Daniel Migault > wrote: > >> >> Thank you all for the comments. I believe there is a misunderstanding of >> the resource issue we are facing, so please find below a more detailed >> description. >> >> The resource in question is neither related to the CPU nor the memory, >> nor the bandwidth as comments seem to suggest but instead related to the >> number of table entries that perform the IPsec processing that varies >> between 720 to 4000 depending on the hardware chip. >> > > Okay. > > > Randomizing the SA lifetime is a probabilistic approach we - and our > customers - do not want to rely on even if the probability of collision > decreases with the SA lifetime. > > So now I am a bit confused. If you are mostly concerned able table length, > then 1 double IPsec SA won't hurt you, but 4000 will. So removing a random > percentage amount of seconds from the initiator would actually > probabilistic fix your issue. 4000 connections with a lifetime of 3600s, > that all start at the same time with a 20% fuzz on initiator would cause > you an extra 5 or 6 SAs. If your code recognises the new SA traffic, and > there is frequent traffic, these double SAs would go away in seconds. So on > a unit that can do 4000 SAs, you can now do only 3994 SAs. > > Am I making a mistake here ? > > Paul > > > > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt
need to > > rekey. Even if they agree via some other mechanism that one end > > should initiate the rekey, what should happen when that rekey is > > not happening? At some point the endpoint not initiating will have > > to tear down or start a rekey anyway. > > Exactly. For this reason I don't think the proposed solution is workable. > > > So why not, instead of a random process, exchange the maximum Child SA > > lifetime accepted before rekey? If the numbers are identical, prefer the > > current exchange initiator. > > > That way, it is deterministic and both endpoints inform the other end > > when (plus or minus some fuzz) a rekey is required. > > It's not enough. There are many cases when rekey is caused not because > of time expiration, but due to other reasons. For example, peer > may count number of bytes sent and rekey after some amount is reached > (when it is critical to limit the number of bytes processed with the same > key). > Or the number of messages sent (when you want to limit the number of > times a key was used for crypto operations). Or just because peer > receives too many packets with invalid ICV and decides that he/she is > under attack trying to break the current key. > > I only mentioned those reasons that we implemented... > > So, there are a lot of reasons for rekey. I think that the ability for any > peer to rekey at any time it thinks it is needed is a fundamental > property of IKEv2 and I think we should not break it. > > Regards, > Valery. > > > Paul > > > > ___ > > 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] minimal esp
rely on" -> "that were relying on" > done * "rather when" -> "rather than when" > done [S6] [nit] * "generate and receive dummy packet" -> "generate and receive dummy packets" > done * "fix value" -> "fixed value" > done ( 2 times) [S8] [nit] * "provided as indicative" -> "provided as information"? > done: provided as informational * "Constraint devices" -> "Constrained devices" > done * "energy associated to it" -> "energy associated with it" > done [S10] [nit] * "associated to the management" -> "associated with the management" > done * "This usually include mechanisms to prevent a nonce to repeat for example." "This usually includes mechanisms to prevent a nonce from repeating, for example." > done * "in conjunction of" -> "in conjunction with" > done * "responsible to negotiate" -> "responsible for negotiating" -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Heads up on Netdev conf 0x15 - not too late to attend!
Hi, For those that have not already attending Netdev, Netdev conf 0x15 has been running since July 7 but it runs for 3 weeks but the talk sessions don't start until Monday. As usual a lot of IETF relevant talks. See: https://netdevconf.info/0x15/accepted-sessions.html The fee is USD $50. Students(proof required) are 50% off. The first 2 weeks was keynote, workshops and tutorials. You can replay all the sessions you missed by entering the conference platform (registration required). The keynote was by Hari Balakrishnan, see: https://netdevconf.info/0x15/session.html?keynote-balakrishnan On Monday as well there will be an industry perspectives panel on smartnics which will involve 6 vendors and an industry veteran moderating the session. For registration go here: https://netdevconf.info/0x15/virtual.html Yours, Daniel -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic
I thought the purpose of the draft was to be able to say "look at this document it says you MUST switch to IKEv2 if you want to remain IPsec interoperable. I am suprised I do not see the MUST in question. I am fine whatever chair/co-authors are fine with. Yours, Daniel On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir wrote: > [no hats] > I don’t want to start (or resume) a religious holy war about uppercase > MUSTs, but they’re usually about protocol compliance. What people should > (not SHOULD) do with their systems is not subject to requirements language, > because the IETF does not engineer administrators. What? You are not > compliant with RFC if you didn’t upgrade your systems already? > > I could understand a statement that Product is not compliant with RFC > because it still offers IKEv1, but I don’t like non-compliant > administrators. Not that I’m advocating to add that statement to the draft. > I think it’s fine as it is: just offering advice that systems should be > upgraded. > > Yoav > > On 29 Jun 2021, at 17:21, Daniel Migault wrote: > > I believe that the first sentence of section 3 says it all. ship it! > > I still have some minor comments, though these may have already been > discussed. There are no normative MUST to upgrade ( and in general very > little normative language). > Shouldn't we have for example: > Systems running IKEv1 should be upgraded and reconfigured to run IKEv2. > > moved to : > > Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2. > > > There are overall very little number of SHOULD/MUST but maybe that is an > editorial choice. > > Yours, > Daniel > > > > > > Yours, > Daniel > > On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins wrote: > >> >>Hi, >> >> On 6/28/21 1:23 AM, Valery Smyslov wrote: >> > Hi, >> > >> > I think document is mostly ready. Few observations: >> > >> > - FWIW I think that Dan's efforts to make draft's language less >> speculative and more concrete >> > are valid and should be reflected in the document. >> > >> > - Is it OK that the intended status is Standards Track? Shouldn't it be >> BCP? >> > >> > - The draft states that it updates RFC 7296, 8221, 8247. What in >> particular is being updated? >> > I believe the recent IESG directives require a short explanation of >> what is being updated >> > to be present in Abstract. In any case, it should be clearly >> indicated in the body of the document. >> > Have I missed it? >> > >> > - Section3: I think that phrase "IKEv2 is a more secure protocol than >> IKEv1 in every aspect." is a bit too vague. >> >>You know, that was bugging me too. "in every aspect" is laying it on >> a bit thick. IKEv1 >> has a security proof. The much maligned PSK mode authenticates the key >> as well as the >> exchange which is better than what IKEv2 does (and why IKEv1 did not >> need an update to do >> PQC). So saying it's less secure "in every aspect" just isn't true. But >> I couldn't figure >> out a better way to say it >> >> >I believe it's better to list security aspects where we believe >> IKEv2 is superior: >> > >> >* IKEv2 supports modern cryptographic primitives, including AEAD >> ciphers >> >* IKEv2 provides real defense against DoS (cookies, core spec) and >> DDoS (puzzles, RFC 8019) attacks >> >* support for post-quantum crypto in IKEv2 is being developed >> (draft-ietf-ipsecme-ikev2-multiple-ke) >> >* IKEv2 supports various authentication methods via integration with >> EAP (core spec) >> >* an extension that allows build PAKE methods in IKEv2 exists (RFC >> 6467) >> >* did I forget something? >> >>But this is great! I agree that such a brief summary of the superior >> features >> would be better than a factually challenged "in every aspect" statement. >> >>regards, >> >>Dan. >> >> -- >> "The object of life is not to be on the side of the majority, but to >> escape finding oneself in the ranks of the insane." -- Marcus Aurelius >> >> ___ >> 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 > > > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic
I believe that the first sentence of section 3 says it all. ship it! I still have some minor comments, though these may have already been discussed. There are no normative MUST to upgrade ( and in general very little normative language). Shouldn't we have for example: Systems running IKEv1 should be upgraded and reconfigured to run IKEv2. moved to : Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2. There are overall very little number of SHOULD/MUST but maybe that is an editorial choice. Yours, Daniel Yours, Daniel On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins wrote: > >Hi, > > On 6/28/21 1:23 AM, Valery Smyslov wrote: > > Hi, > > > > I think document is mostly ready. Few observations: > > > > - FWIW I think that Dan's efforts to make draft's language less > speculative and more concrete > > are valid and should be reflected in the document. > > > > - Is it OK that the intended status is Standards Track? Shouldn't it be > BCP? > > > > - The draft states that it updates RFC 7296, 8221, 8247. What in > particular is being updated? > > I believe the recent IESG directives require a short explanation of > what is being updated > > to be present in Abstract. In any case, it should be clearly > indicated in the body of the document. > > Have I missed it? > > > > - Section3: I think that phrase "IKEv2 is a more secure protocol than > IKEv1 in every aspect." is a bit too vague. > >You know, that was bugging me too. "in every aspect" is laying it on > a bit thick. IKEv1 > has a security proof. The much maligned PSK mode authenticates the key > as well as the > exchange which is better than what IKEv2 does (and why IKEv1 did not > need an update to do > PQC). So saying it's less secure "in every aspect" just isn't true. But > I couldn't figure > out a better way to say it > > >I believe it's better to list security aspects where we believe IKEv2 > is superior: > > > >* IKEv2 supports modern cryptographic primitives, including AEAD > ciphers > >* IKEv2 provides real defense against DoS (cookies, core spec) and > DDoS (puzzles, RFC 8019) attacks > >* support for post-quantum crypto in IKEv2 is being developed > (draft-ietf-ipsecme-ikev2-multiple-ke) > >* IKEv2 supports various authentication methods via integration with > EAP (core spec) > >* an extension that allows build PAKE methods in IKEv2 exists (RFC > 6467) > >* did I forget something? > >But this is great! I agree that such a brief summary of the superior > features > would be better than a factually challenged "in every aspect" statement. > >regards, > >Dan. > > -- > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius > > ___ > 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] Fwd: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-05.txt
Hi, Please find the current version that addresses all concerns currently received. Yours, Daniel -- Forwarded message - From: Date: Tue, Apr 13, 2021 at 11:29 AM Subject: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-05.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : Minimal ESP Authors : Daniel Migault Tobias Guggemos Filename: draft-ietf-lwig-minimal-esp-05.txt Pages : 15 Date: 2021-04-13 Abstract: This document describes a minimal implementation of the IP Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options to remain compatible with ESP as described in RFC 4303. A minimal version of ESP is not intended to become a replacement of the RFC 4303 ESP. Instead, a minimal implementation is expected to be optimized for constrained environment while remaining interoperable with implementations of RFC 4303 ESP. Some constrains include limiting the number of flash writes, handling frequent wakeup / sleep states, limiting wakeup time, or reducing the use of random generation. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. RFC 4303 remains the authoritative description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-minimal-esp-05 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-minimal-esp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-minimal-esp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lwip mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lwip -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] Iotdir last call review of draft-ietf-lwig-minimal-esp-03
Hi Nancy, Regarding ISSUE 3, I have the impression that the concern that AES-GCM, Chacha20-Poly1305 or AES-CCM only send a 64 bit IV which suggest that only 64 bit IV can be sent with ESP. In fact the IV is not a field in ESP but is defined for each suite, as a result, ESP would be able to support any suite with larger or short IV. Then, the use of a 96 bit nonce is not uncommon, actually AES-GCM and Chacha20-Poly1305 do use 96 bit nonce and AES-CCM uses a 88 bit nonce. The nonce is formed based on a slat and the IV. Similar construction may be provided for AES-GCM-SIV if needed as far as I can see. AES-GCM-SIV is only defined as an algorithm, I also suggest to add other alternatives that have a similar goals. The current text is as follows and I think it might close the ISSUE 3. When the key is likely to be re-used across reboots, it is RECOMMENDED to consider algorithms that are nonce misuse resistant such as, for example, AES-SIV [RFC5297], AES-GCM-SIV [RFC8452] or Deoxys-II [deoxys]. Note however that currently none of them has yet been defined for ESP. I suspect the ISSUE 1 and ISSUE 2 are related to IV collision. If so it seems to me related to the collision of IV. If so I think the current proposed text for SN addresses the concerns that an algorithm should not be used beyond its limits. In addition the following text in the security consideration seems to address that concern as well: the nodes MUST ensure that keys are not used beyond their lifetime and that the appropriate use of the key remains across reboots - e.g. conditions on counters and nonces remains valid. I suspect that collision is related to the collision of IV which is only a concern when the IV needs to be unpredictable. I am tempted to think that algorithms that the properties of the IV are really part of the algorithm properties and that they cover / include into the lifetime of the keys. On the other hand, most recommended algorithms AES-GCM, AES-CCM, Chacha-Poly1305 are using IVs that just do not need to repeat, and so use counters where collision is not a concern. Of course this does not concerne collision across reboot, but I do not think these were the collisions that caused your concern. If I am correct, that probably also addresses ISSUEs 1 and ISSUE 2. I will publish the version with the current changes so reviews have the most recent editorial changes and will update from that according to your response. Again thank you for the in depth review and the many comments that already result in many clarifications - at least I think so. Yours, Daniel On Tue, Mar 30, 2021 at 10:45 PM Daniel Migault wrote: > Hi Nancy, > > Thank you very much for your review. Please see inline my responses. I > believe all concerns raised have been addressed. I also believe the current > text addresses some concerns also raised by Paul W. > > The current version can be found here: > > https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89 > > I think there are however three remaining issues that might get further > discussions. For all of these I provided a response, but I am unsure it > really addresses the three concerns below: > > > ISSUE 1 > > - I might challenge due to potential collision attacks that at > most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN > and how > it is used is part of the security context for the SPI/SA. I might also > challenge that a recommendation for using a rekey mechanism is warranted > because constrained devices tend to stay up for very, very, very long > periods > of time and even with an ESN there can be exhaustion :-) > > I am missing the concern. I understand the first concern is that the > current text seems to push the limit of packets being sent being determined > by the SN as opposed to cryptographic properties. If my understanding is > correct, I have the current text seems clear that crypto properties are > given priorities. I suspect more guidance would be given. If that is the > case, I find it difficult as these guidances are really based on the > cryptographic algorithm and the key sizes. In any case, if I am > missing something, feel free to propose some text. > > """ > Note that the limit of messages being sent is primarily determined by the > security associated with the key rather than the SN. > The security of all data protected under a given key decreases slightly > with each message and a node MUST ensure the limit is not reached - even > though the SN would permit it. > """ > > I understand the second concern as that current text is read as rekey > mechanisms are recommended only when there is a risk the SN get exhausted. > Our intention was to read the text as even if ESN raises the limit to an > acceptable limit, it i
Re: [IPsec] secdir review of draft-ietf-lwig-minimal-esp-03
Hi David, Thanks the review. I think the text in [1] addresses your concern. I will probably publish the a new version today. Please see my responses inline. Yours, Daniel [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89 -Original Message- From: David Mandelberg Sent: Saturday, March 27, 2021 5:39 PM To: i...@ietf.org; sec...@ietf.org; draft-ietf-lwig-minimal-esp@ietf.org Subject: secdir review of draft-ietf-lwig-minimal-esp-03 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. (Section 3, nit) In the paragraph that includes "However, nonrandom SPI and restricting their possible values MAY lead to privacy and security concerns" , it would be nice to add something like "(see below for more details)". When I first read that paragraph, I was about to comment that it's unclear what the privacy/security concerns are, but then it was explained a few paragraphs below. That is correct, we restructured a bit the section to clarify this by having a subsection dedicated to considerations over the generation of SPIs. The current section is available at [1] and is mentioned below: [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89 SPI that are not randomly generated over 32 bits MAY lead to privacy and security concerns. As a result, the use of alternative designs requires careful security and privacy reviews. This section provides some considerations upon the adoption of alternative designs. Note that SPI value is used only for inbound traffic, as such the SPI negotiated with IKEv2 or by a peer, is the value used by the remote peer when it sends traffic. As SPI is only used for inbound traffic by the peer, this allows each peer to manage the set of SPIs used for its inbound traffic. Similarly, the privacy concerns associated with the generation of nonrandom SPI is also limited to the incoming traffic. When alternate designs are considered, it is likely that the number of possible SPIs will be limited. This limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey. SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the Security Association Database (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. The use of a smaller number of SPIs across communications comes with privacy and security concerns. Typically some specific values or subset of SPI values may reveal the models or manufacturer of the node implementing ESP. This may raise some privacy issues as an observer is likely to be able to determine the constrained devices of the network. In some cases, these nodes may host a very limited number of applications - typically a single application - in which case the SPI would provide some information related to the application of the user. In addition, the device or application may be associated with some vulnerabilities, in which case specific SPI values may be used by an attacker to discover vulnerabilities. While the use of randomly generated SPI may reduce the leakage or privacy or security related information by ESP itself, these information may also be leaked otherwise and a privacy analysis should consider at least the type of information as well the traffic pattern. Typically, temperature sensors, wind sensors, used outdoors do not leak privacy sensitive information and mosty of its traffic is expected to be outbound traffic. When used indoors, a sensor that reports every minute an encrypted status of the door (closed or opened) leaks truly little privacy sensitive information outside the local network. (Section 4) Am I understanding correctly, that the last paragraph is giving the option of resetting the Sequence Number when rekeying? Does IPSec try to prevent eavesdroppers from determining when rekeying happens? (I really don't know that much about IPSec.) If it does, then resetting the SN could leak that information, if not then there's nothing to leak. No. The last sentence of the section intended to prevent implementers to only consider the SN to define the life time of their SA. If implementer choose to use ESN for that purpose, it might be a good indication that a re-key mechanism is needed. The current text has been updated to clarify this by the following text: """ Note that the limit of
Re: [IPsec] [Lwip] Iotdir last call review of draft-ietf-lwig-minimal-esp-03
s likely to be re-used across reboots, it is RECOMMENDED to consider transforms that are nonce misuse resistant such as AES-GCM-SIV for example. Note however that AES-GCM-SIV has not yet been defined for ESP. """ > - What is the point driven in “interoperability”? Is it that constrained > devices may have limited interoperability given that they may not support > all > ciphers in RFC 8221? It is more that what the other nodes supports needs to be considered in the selection of the cipher suite. While RFC 8221 ensures smooth transition, contrainted devices have less interoperability requirements. > - Similarly, for the power consumption and cipher suite > complexity; is the point that ciphers are chosen based on the constraints > (physical, computational and memory) of the device? > > yes. > Nits: > General throughout the draft: “constraint devices” should be “constrained > devices”. > > thanks. I changed them all. > Abstract: > - Last sentence of first paragraph first clause is awkward “Constrains > include > among other limiting….” > Perhaps you mean “Some constraints include limiting the…” > done. thanks. > - Some qualification of “what is required from RFC 4303” is required…. > Perhaps you mean “the minimally required set of functions and states from > RFC > 4303 to achieve compliance and interoperability”? My suggestion may be to > just > remove this 2nd paragraph as its covered in the 3rd (though I think noting > interoperability should be there too). > I agree. done. > - I would think that there would be a strong issue if there are conflicts > with > RFC 4303?! So would suggest to remove that sentence or > Only that the RFC 4303 remains the authoritative spec to detail full > details of > ESP. > > done. thanks > Section 2: > - “constraint devices” should be “constrained devices” > > Section 8: > - For “Security”, suggest…”The chosen encryption algorithm MUST NOT be > known to > be vulnerable or weak” > > done. thanks. > > > ___ > Lwip mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-03.txt
Hi, Please find below the updated version of the draft as detailed in [1] and [2] as well as some nits. The main changes are that we introduced some more context on the constraints a device may have which could clarify the motivations for the optimizations that were detailed. This includes the context being provided in the abstract, introduction, as well as for SPI, SN sections. Having not heard any feedbacks to [1] and [2] I believe these updates address the concerns raised. Yours, Daniel [1] https://mailarchive.ietf.org/arch/msg/lwip/IHyy2OCA-hWWfjxDrkX-x1yAvFI/ [2] https://mailarchive.ietf.org/arch/msg/lwip/vBtGKO_0GU_SUNkfu-iSUC-Bq9A/ On Wed, Mar 24, 2021 at 11:11 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Light-Weight Implementation Guidance WG > of the IETF. > > Title : Minimal ESP > Authors : Daniel Migault > Tobias Guggemos > Filename: draft-ietf-lwig-minimal-esp-03.txt > Pages : 14 > Date: 2021-03-24 > > Abstract: >This document describes a minimal implementation of the IP >Encapsulation Security Payload (ESP) defined in RFC 4303. Its >purpose is to enable implementation of ESP with a minimal set of >options to remain compatible with ESP as described in RFC 4303. A >minimal version of ESP is not intended to become a replacement of the >RFC 4303 ESP. Instead, a minimal implementation is expected to be >optimized for constrained environment while remaining interoperable >with implementations of RFC 4303 ESP. Constrains include among other >limiting the number of flash writes, handling frequent wakeup / sleep >states, limiting wakeup time, or reducing the use of random >generation. > >This document describes what is required from RFC 4303 ESP as well as >various ways to optimize compliance with RFC 4303 ESP. > >This document does not update or modify RFC 4303, but provides a >compact description of how to implement the minimal version of the >protocol. If this document and RFC 4303 conflicts, then RFC 4303 is >the authoritative description. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lwig-minimal-esp-03 > https://datatracker.ietf.org/doc/html/draft-ietf-lwig-minimal-esp-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-minimal-esp-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > Lwip mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup
addresses - as well as the ability for the node to rekey. SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the Security Association Databas e (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the re key index. > - clarify why counter as entire IV is okay (because AEAD) and why >storing an absolute counter on flash is bad, and timing can be used >instead. > The text already mentions RFC8750 > - Clarify why sequence numbers cannot be sequential - flash writes are >bad. > Text proposed by Tero has been included. > - A clear section on why AES-CBC/3DES-CBC cannot be used due to IV >randomness limitations > The text delegates the crypto recommendations to 8221 which mentions 3DES has should not and mentions AES_CBC to be replaced. I do not think that the discussion should be duplicated here. In addition the text mentions the following recommendations: - Use of counter-based ciphers without fixed block length (e.g. AES-CTR, or ChaCha20-Poly1305). - Use of ciphers recommended for IoT *[*RFC8221]. > - clearly recommending an AEAD like AES-CCM or AES-GCM. Consider using >their IV-less names from RFC 8750. > The text mentions as a second recommendation: - Use of ciphers with capability of using implicit IVs *[*RFC8750]. > - Remove reference to AES-GCM-SIV which does not exist for ESP, or >clarify "once/if available for ESP". > ESP does not define transform these are defined by IKE. AES-GCM-SIV is the algorithm not the transform. See my response in my previous email. > - call "ChaCha20-Poly1305" by its name CHACHA20_POLY1305 (and maybe also >by its RFC 8750 name) > The ChaCha20-Poly1305 is mentioned for its cryptography properties not as a transform. These remain independent of the multiple associated transform using it. Again the choice of the specific transform is delegated to RFC8221. > - clarifying section 6 that this is not about the Next Header (being >removed) but just about not supporting dummy packets. Probably change >the title of the section too. > I understand the problem was a mis interpretation of the dummy packet which has been clarified with the following text: """ i.e. packets with the Next Header with a value 59 meaning "no next header". """ > - change "cryptographic suites" and "crypto-suites" to "cryptographic >algorithms" to avoid TLS confusion > I think IKEv2 uses suites or transform. > - update the introduction to introduce the constrains (flash writes, >wake/up sleep vs reboot, getrandom limitations) > The text has been updated with : As a result, constraint devices are likely to have their own implementation of ESP optimized and adapted to t heir specificities such as limiting the number of flash writes (for each packets or across wake time), handli ng frequence wake/up sleep while limiting wake time, or reducing the use of random generation. > - figure out what to do with the FIPS reference on randomness (because >I don't think with continuous self test, it can be fully FIPS >compliant?) > The reference has been kept as suggested by Scott. > - Clarify the list in section 8. Is this ordered from most important >to least important? I think so but it does not state this. > I find it difficult to define a universal order. > - Remove reference to I-D.nikander-esp-beet-mode, with the text "not >standarized yet". This draft has been abandoned in 13 years ago. > > I think it is useful to keep the text mentioning that in some case NH is used otherwise but we do not have to bother. While not standardized, it is implemented and used. I agree though it is not essential, but I do not see it as hurting. > I'm willing to help with text if the authors want, but I think if I did > that, the diff would be quite large as I would be clarifying things be > being more epxlicit and use fewer words. So it might be better if the > goal is to keep the changes to a minimum for the draft authors to make > the changes. > > We want to keep the changes minimal also to avoid overwriting text that has been agreed before. > Paul > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup
Hi Paul, A large part of your comments result from a confusion between the use of SPI in IKE and ESP. This discussion has already been set in [1]. Other comments currently led to two minor updates in the document that have been published here [2]. So far I believe your concerns have been addressed unless I am misunderstood them. Please find my responses in line. Yours, Daniel [1] https://mailarchive.ietf.org/arch/msg/lwip/ygw567rdae2LLXoWTbdbXMejowI/ [2] https://github.com/mglt/draft-mglt-lwig-minimal-esp/blob/master/draft-ietf-lwig-minimal-esp.xml On Mon, Mar 22, 2021 at 12:12 AM Paul Wouters wrote: > On Sun, 21 Mar 2021, Daniel Migault wrote: > > (replying to some issues here, but also added a full review of the > document) > > Side note: I am bit confused why this document would not be a document > from the IPsecME WG ? I know we talked about this before? Did we decide > against adoption at IPsecME ? Can the authors, WG chairs of IPsecME or > the responsible AD shed some light on the history here? > > The document minimal esp complements minimal IKEv2 RFC 7815 that was adopted in LWIG and the goal of the document seems in scope with LWIG, that is building minimal interoperable IP capable devices for the most constrained environment. As the matter (ESP) might involve the IPsec community we always cced the ipsecme as well as by making presentations during ipsecme sessions. Maybe you could clarify what in particular you find confusing. In general, this draft is very "wordy" because it is trying to steer > itself around a lot of problems, without making firm decisions. But the point of an RFC is that it should make clear decisions that > implementers can adopt clearly. The scope of the document is to provide guidance for implementers on minimal implementations while remaining interoperable. The techniques an implementer will choose depend on its constraints and environment and there is not an intention to favor one technique over the others. This document and describes how an implementer may achieve a minimal implementation while remaining interoperable. Decision of what to implement is let to the implementer. > As such, I'm not in favour of this > draft. I believe I stated this before? > > > [1] > https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/47f1351b1928ba687af18e75e253e98720448e8e > > On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M 40ericsson@dmarc.ietf.org> wrote: > > I am now preparing the shepherd writeup for > draft-ietf-lwig-minimal-esp. > > I wanted to clarify and double check a few things: > > > > - If the SPI is not random and is chosen by some application > specific > > method -> it can reveal the application using ESP. > > > > > > It is correct that the use of non random SPI may have some privacy > impacts and one of these impacts is that in some cases, a SPI may be used > to track an application. Note that our intention was to make it > > clear that when SPI are non randomly generated, there are some privacy > implications to consider as well as that randomly generated SPI is > preferred. > > At the time I also mentioned one attack against IKE that was twarted by > having 4 random bytes as SPI. It remains dangerous to change this > property of ESP, and I recommended to not do that. > > https://access.redhat.com/blogs/product-security/posts/sloth > > But it seems that although my comments caused the draft to be modified, > it still allows non-random SPIs: > > However, for some constrained nodes, generating and handling 32 bit > random SPI may consume too much resource, in which case SPI can be > generated using predictable functions or end up in a using a subset > of the possible values for SPI. In fact, the SPI does not > necessarily need to be randomly generated. A node provisioned with > keys by a third party - e.g. that does not generate them - and that > uses a transform that does not needs random data may not have such > random generators. However, nonrandom SPI and restricting their > possible values MAY lead to privacy and security concerns. As a > result, this alternative should be considered for devices that would > be strongly impacted by the generation of a random SPI and after > understanding the privacy and security impact of generating nonrandom > SPI. > > So I feel I raised a security issue, and the text just copied my concern > but still basically states implementations MAY do this. I believe this > is wrong. > The security concerned you raised is irrelevant here. The SLOTH attack only concerns SIGMA protocols and ESP does not involve any SIGMA protocols. This concern has been addressed and you agreed in the following words [1]
Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup
he value of the time itself. This could be used with a clock that is 2 years back in the past or in the future. It is correct that a few packet analysis may reveal how synchronized the clock of the device is. Regarding the time the packet has been sent, it seems to me this is relatively close to the time the time is captured, but maybe I am missing how this could be used or any specific cases where delay tolerant networks are involved. So I am inclined to say that yes this may leak some information, but this information may already be leaked. > - Are we comfortable with the recommendation: 'A node MAY drop > anti-replay protection provided by IPsec, and instead implement its own > internal mechanism.'? What might this internal mechanism look like? > > Enabling anti reply protection is no mandatory, so that is the default. RFC4303 mentions: """ The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. """ Some mechanisms that come to my mind are implementations that receive packets in a very deterministic manner. Note that the document recommends to enable anti-replay. > A few typos: > > - > > Section 3: > > Please expand SAD on first usage. > fixed. Thanks for raising that issue. > > Section 4: > > Typo: In a constrainted environment -> In a constrained environment > > fixed. I also check there are no other occurrence and it seemed that was the only occurrence. I looked at old RFCs and they seem to use both crypto-suite and > cryptosuite. I have a preference for the later. Perhaps we can remove > the hyphen. > > I have removed the occurrences I found of crypt-suite and replaced them by cryptosuite. > - > > --Mohit > > > > ___ > Lwip mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
