Hi Tero,
Thanks for the comments. Please find below how I updated the text on my
local copy and let me know if that addresses your concerns.
Yours,
Daniel
On Fri, Oct 30, 2020 at 3:26 PM Tero Kivinen wrote:
> Daniel Migault writes:
> >value SN needs to be considered instead.
Hi Tero,
Thanks for the comments. Please find below how I updated the text on my
local copy and let me know if that addresses your concerns.
Yours,
Daniel
On Fri, Oct 30, 2020 at 3:13 PM Tero Kivinen wrote:
> Daniel Migault writes:
> > The security consideration has been updated a
ndom generators based on deterministic random functions.
"""
I believe that we do not necessarily need to go into more details that are
related to specific transforms, but I am happy to hear otherwise.
Yours,
Daniel
On Mon, Nov 2, 2020 at 9:00 AM Tero Kivinen wrote:
> Daniel Mig
ernet-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-0
I agree that standard track is more appropriated. I agree the document should
go and be published.
Yours,
Daniel
-Original Message-
From: Lwip On Behalf Of Rene Struik
Sent: Sunday, November 15, 2020 6:59 PM
To: lwip@ietf.org
Subject: Re: [Lwip] I-D Action: draft-ietf-lwig-curve-represe
I personally do not see at that stage a clear advantage of adding another round
to secdispatch and - again speaking only for myself - I would prefer at that
point to see the document being moved forward in lwig with the status that
enables all IANA registration.
Yours,
Daniel
_
d 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
>
>
>
> ___
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
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 refer
t;
> Title : Minimal ESP
> Authors : Daniel Migault
> Tobias Guggemos
> Filename: draft-ietf-lwig-minimal-esp-03.txt
> Pages : 14
> Date: 2021-03-24
>
> Abstra
an “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
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>
--
Daniel Migault
Ericsson
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
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
-
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 yo
Hi Roni,
Thanks for the review. We can of course add that RFC4303 is authoritative in
the main body. I will update the document.
I am wondering what differences you have in mind. Of course the document are
different but I am wondering if there is anything we should clarify.
Yours,
Daniel
y but it was my mistake. So forget this comment. Still you use
> authentication while RFC4303 use integrity but the recommendation is the
> same.
> Roni
>
> > -Original Message-
> > From: Daniel Migault [mailto:daniel.miga...@ericsson.com]
> > Sent: Saturday
Hi Roni,
As a follow up, I just posted version 05 that reflects the change to
address your concern.
Yours,
Daniel
On Thu, Apr 8, 2021 at 9:33 AM Daniel Migault wrote:
> Hi Roni,
>
> Thanks for the clarification.
>
> Yours,
> Daniel
>
> On Thu, Apr 8, 2021 at 2:40 AM R
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
t; "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
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
gt; If anything, the draft ought *not* to recommend against TFC, which is only
> on
> the spurious grounds than non-IoT applications have tended not to need it.
>
> Padding/dummy packet are likely to remain sufficient. If that is not the
case
Hi Bob,
I am willing to publish the changes on the git. Let me know if you are
planning to do a pull request or if you have any additional comments.
Yours,
Daniel
On Thu, Sep 2, 2021 at 5:37 PM Daniel Migault wrote:
> Hi Bob,
>
> Thanks for the careful review. I am responding inlin
7;.
>
> Pls see inline, tagged [BB]...
>
> On 24/09/2021 15:04, Daniel Migault wrote:
>
> Hi Bob,
>
> I am willing to publish the changes on the git. Let me know if you are
> planning to do a pull request or if you have any additional comments.
>
> Yours,
> Dan
I seems reasonable this document passes the IESG before the IESG get renewed as
it currently has in mind the history of the draft.
I understand this draft get a higher priority over the remaining draft in lwig.
Yours,
Daniel
From: Lwip on behalf of Rene
.
>
> coma added
> Section 5. , paragraph 4, nit:
> > ent with a size different from zero. It length is defined by the
> security rec
> > ^^
> It seems that the possessive pronoun "its" fits better in this contex
ge of not maintaining states for every
packet. Keeping that 10 packet state ends up in maintaining state for every
packet sent/received. It could be useful if state maintenance is not an
issue for that node which connects nodes with state constraints.
>
>
> _________
tract of RFC4303 which
defines ESP.
RFC4303:
"""
ESP is used to provide confidentiality, data origin authentication,
connectionless
integrity, an anti-replay service (a form of partial sequence
integrity), and limited traffic flow confidentiality.
&
On Wed, Apr 6, 2022 at 5:01 AM Lars Eggert wrote:
> Hi,
>
> On 2022-4-6, at 5:05, Daniel Migault wrote:
> > Section 2. , paragraph 6, comment:
> > >[RFC4303] does not require the SPI to be randomly generated over 32
> > >bits. However, this is the recom
thms.
> Editorial
> -- Section 3. Typo. s/know whereas the received/know whether the
> received/
>
> -- Section 3. Editorial. s/sending a temperature/sending a temperature
> measurement/
>
> -- Section 3. s/sending a temperature/sending a temperature measurement/
>
> --
ncapsulating Security Payload (ESP)
> Authors : Daniel Migault
> Tobias Guggemos
> Filename: draft-ietf-lwig-minimal-esp-10.txt
> Pages : 15
> Date: 2022-04-08
>
> Abstract:
>This
, 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 parti
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
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
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 exchange
at 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
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
ballot.
>
>
>
> Roman
>
>
>
> *From:* Daniel Migault
> *Sent:* Thursday, April 7, 2022 1:29 PM
> *To:* Roman Danyliw
> *Cc:* The IESG ; lwip@ietf.org; Mohit Sethi <
> mohit.m.se...@ericsson.com>; draft-ietf-lwig-minimal-...@ietf.org;
> lwig-cha...@ietf.o
provides a
compact description of the minimal version of the protocol. If this
document and RFC 4303 conflicts then RFC 4303 is the authoritative
description.
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
___
Lwip mailing list
Lwip
think your draft might be useful for LWIG WG though.
>
> Cheers
> Sye Loong
>
> -Original Message-
> From: dtls-iot [mailto:dtls-iot-boun...@ietf.org] On Behalf Of Daniel Migault
> Sent: Friday, 31 January, 2014 10:48 PM
> To: ip...@ietf.org; dtls-...@ietf.org
&g
(CZ) wrote:
> Hi , Daniel,
>
> What's the relationship with existing work on ikev2, and tls?
>
> Thanks,
> Zhen
>
>> -Original Message-
>> From: Lwip [mailto:lwip-boun...@ietf.org] On Behalf Of Daniel Migault
>> Sent: Friday, January 31, 2014 10:
rotocol behavior
> modifications beyond what is already allowed by existing RFCs, because
> it is important to ensure that different types of devices can work together.
> "
>
>
> Ciao
> Hannes
>
> On 02/13/2014 02:45 PM, Daniel Migault wrote:
>> Hi,
>>
>&g
(we only consider "low-power" radios, with transmit powers lower than
about 10mW).
Roughly speaking, this means that, for the energy cost of exchanging 1
bit, our system can alternatively compute 10-100 instructions.
> Regards,
> Valery Smyslov.
>
>
Best Regards,
Daniel
>
&
enders even though it knows the
receiver does not use anti replay protection.
- clarification / rewording
- Padding section
Feel free to make comments!
[1] http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-01.txt
BR
Daniel
--
Daniel Migault
Orange Labs -- Security
+33 6 70
on Lwig@IETF90, could you please let us know before
> this Friday.
>
>
>
> Many thanks,
>
> Robert & Zhen
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>
>
Hi,
I agree with Tero that doing full protocol performance analysis is more
interesting than just comparing cryptographic algorithms.
In our tests, compared to unprotected packets, the power consumption for
encryption did not exceeded a few percents, whereas ESP has a significant
network overh
Hi,
My personnal opinion is that the copied text in this document is useful for
the understanding of how the minimal IKEv2 works. It also makes the
document easier to read and reduces the number of jumps from the IKEv2 spec
and the minimal implementation doc.
The counter part is that changes of IK
Please find the new version of our minimal ESP draft. Comments and suggestions
are welcome!
BR,
Daniel
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, March 21, 2016 10:53 AM
To: Daniel Palomares; Daniel Migault; Tobias Guggemos
Hi,
I have read the draft. The scope of the draft is useful for the WG. In my
opinion, the current draft needs some editorial changes which should not
prevent it to be adopted as a WG document. I support the adoption of this
document.
BR,
Daniel
On Thu, Jun 30, 2016 at 6:11 AM, Mohit Sethi
wrot
As mentioned on the list outside the thread, I support the adoption of the
draft.
BR,
Daniel
-Original Message-
From: Lwip [mailto:lwip-boun...@ietf.org] On Behalf Of Renzo Navas
Sent: Tuesday, August 02, 2016 12:00 PM
To: lwip@ietf.org
Cc: draft-aks-lwig-crypto-sens...@tools.ietf.org
S
Hi,
Please find an update of a guidance for light implementation of standard ESP.
Feel free to comment!
Yours,
Daniel
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, March 13, 2017 9:57 AM
To: Tobias Guggemos ; Daniel Migault
gateways implements the longest
match lookup or at least lookup considering IP addresses ?
Yours,
Daniel
On Mon, Mar 13, 2017 at 9:58 AM, Daniel Migault wrote:
> Hi,
>
> Please find an update of a guidance for light implementation of standard
> ESP. Feel free to comment!
>
&g
guess that multipurpose interoperability is achieved with the longest match
lookup. But I agree I am also confused.
Yours,
Daniel
-Original Message-
From: paul.kon...@dell.com [mailto:paul.kon...@dell.com]
Sent: Friday, March 24, 2017 4:25 PM
To: Daniel Migault
Subject: Re: [IPsec
limited number of SPI are on the node side.Thanks!
On Sun, Mar 26, 2017 at 1:45 PM, Tero Kivinen wrote:
> Daniel Migault writes:
> > For unicast communications, a single SPI can be used over multiple
> > nodes as long as the remote peer, as long as both nodes uses IP
> > addre
the crypto-suite used. Currently recommended
<> only recommend crypto-suites with an ICV which
makes the ICV a mandatory field.
"""
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Tuesday, May 16, 2017 3:54 PM
To: Tobias Guggemos ;
Hi Heinrich,
Thank you for reviewing the draft. Please find my response inline. I
believe your concerns are addressed in the draft within the scope of the
draft. The work you are mostly looking at would be an efficient TFC / dummy
packet policy. This would more probably be in scope of ipsecme WG.
As a co-author, I am supporting the adoption of the document. I believe
this is important so lightweight implementation of ESP remains compatible
with the standard ESP.
Yours,
Daniel
On Thu, Aug 23, 2018 at 3:51 AM, IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:
>
> The LWIG WG has p
ice.
>
>
Thisis correct. I mentioned it as maybe a starting point for the specific
topic your mentioned.
> Ciao
> Heinrich
>
> On Wed, 29 Aug 2018 at 19:17, Daniel Migault
> wrote:
>
>> Hi Heinrich,
>>
>> Thank you for reviewing the draft. Please find my r
Hi,
Just to mention that of course, the draft will be updated to reflect the
discussions / clarifications raised on the mailing list.
Yours,
Daniel
On Tue, Sep 4, 2018 at 4:07 AM Mohit Sethi
wrote:
> Hi Tero,
>
> You raise some very interesting points here.
>
> I personally think that the draf
Thanks for the feed back, we will careful on the wording and make sure we
address this.
Thanks,
Yours,
Daniel
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
: Daniel Migault
Tobias Guggemos
Filename: draft-mglt-lwig-minimal-esp-07.txt
Pages : 13
Date: 2018-10-21
Abstract:
This document describes a minimal implementation of the IP
Encapsulation Security Payload (ESP
Hi,
I am wondering what is currently the status of the draft. Feel free to let
me know if I something is expected on my side.
Yours,
Daniel
On Thu, Oct 25, 2018 at 3:05 AM Mohit Sethi M
wrote:
> Hi Paul, Heinrich and Tero,
>
> The authors have updated the draft based on the feedback received:
e guidance on lightweight implementations.
Almost all drafts in this WG are informational in nature and we don't intend
to change existing standards or define new ones.
"""
[4] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06
-Original Message-
From:
-Original Message-
From: internet-dra...@ietf.org
Sent: Sunday, April 07, 2019 4:11 PM
To: Tobias Guggemos ; Daniel Migault
Subject: New Version Notification for draft-ietf-lwig-minimal-esp-00.txt
A new version of I-D, draft-ietf-lwig-minimal-esp-00.txt
has been successfully submitted
Thanks Scott for the comment. I will address them tomorrow, I am just
sharing the review to the lwig list.
Yours,
Daniel
On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer)
wrote:
> Comments:
>
>
>
>- I have issues with the draft’s emphasis on fixed SPI values. One
>reason for the
; Best regards, Rene
>
> On 10/25/2019 2:38 PM, Daniel Migault via Datatracker wrote:
>
> Reviewer: Daniel Migault
> Review result: Almost Ready
>
> Hi,
>
> I have reviewed this document as part of the IoT directorate's
> ongoing effort to review all IETF docume
Thank you Valery for the detailed review. That is really much appreciated.
We will update the document accordingly by the next few weeks also
considering the feed backs from Scott.
Yours,
Daniel
On Tue, Dec 3, 2019 at 8:08 AM Valery Smyslov
wrote:
> Hi,
>
> I reviewed draft-ietf-lwig-minimal-es
Struik
Sent: Tuesday, July 14, 2020 1:43 PM
To: Daniel Migault ; iot-...@ietf.org
Cc: lwip@ietf.org ;
draft-ietf-lwig-curve-representations@ietf.org
Subject: Re: Iotdir early review of draft-ietf-lwig-curve-representations-08
Hi Daniel:
It has been a while that you provided your early
are more than Examples ;-)
Yours,
Daniel
On Mon, Jul 20, 2020 at 9:54 AM Daniel Migault wrote:
> Hi Rene,
>
> Thank you for the feed back - I am just back from vacation. As far as I
> remember, my comments mostly concerned some clarifications and should not
> be seen as p
From: Rene Struik
Sent: Monday, August 10, 2020 3:13 PM
To: Daniel Migault ; Daniel Migault
Cc: iot-...@ietf.org ; lwip@ietf.org ;
draft-ietf-lwig-curve-representations@ietf.org
Subject: Re: [Lwip] Iotdir early review of
draft-ietf-lwig-curve-representations-08
Hi Daniel:
Thanks for your
r example[RFC8452]
"""
>
>-
>
>
> Typos:
>
>- a random SPI may consume to much -> too much
>- fix SPI -> fixed SPI
>- can be alleviate -> can be alleviated
>- algorythm -> algorithm
>-
>
>
fixed
>
>-
>
> ___
> IPsec mailing list
> ip...@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
--
Daniel Migault
Ericsson
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
will be more
>sensitive to traffic shaping.
>
> s/cannot not/cannot
> s/minimal/minimal ESP
> s/were relying/rely
>
> Section 7:
>
>Currently recommended
>[RFC8221] only recommend crypto-suites with an ICV which makes the
>ICV a mandatory field.
>
> s/recommend/recommends
>
>
fixed
> Section 8:
>
>The recommended suites to use are expect to evolve over time
>and implementer SHOULD follow the recommendations provided by
>[RFC8221] and updates.
>
> s/expect/expected
> s/implementer/implementers
>
>
fixed
>Note that it
>is not because a encryption algorithm transform is widely
>deployed that is secured.
>
> s/a/an
>
fixed
>
> Regards,
> Valery Smyslov.
>
>
>
--
Daniel Migault
Ericsson
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
: Daniel Migault
Tobias Guggemos
Filename: draft-ietf-lwig-minimal-esp-01.txt
Pages : 14
Date: 2020-10-28
Abstract:
This document describes a minimal implementation of the IP
Encapsulation Security Payload (ESP) defined
Reviewer: Daniel Migault
Review result: Almost Ready
Hi,
I have reviewed this document as part of the IoT directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
internet area directors. Doc
70 matches
Mail list logo
