: 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
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
ents 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,
>
&
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
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:*
k 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&
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/m
ncluding 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
>
is
> 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
__
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
;>
>> _______
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>> ___
>> 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
Yours,
Daniel
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
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
n 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:
>
&g
-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
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
; ___
> 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
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 S
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 bas
/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]
>>
>> &
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 y
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
On Wed, Aug 2, 2023 at 10:29 PM Christian Hopps wrote:
>
> Daniel Migault writes:
>
> > 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
imum 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.
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
pular 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.
&
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
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
o 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:*
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 No
erned flow.
Yours,
Daniel
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
er 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
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
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
> > wo
ed 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
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/dra
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
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
-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
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 post
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, 202
odepoints " (to be
published soon)
Yours,
Daniel
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
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 t
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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMTU_R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> On Jan 4, 2023, at 7:21 PM,
:
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 compl
up 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 ma
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 upda
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 (EMT
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.
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 pa
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.or
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
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
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&g
gt;
> >
> >
> > ___
> > 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
gt;
>
>
> ___
> 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
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
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://ww
e 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
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
> wond
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
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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
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
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
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
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 overl
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
ayer 5
> protocols (CoAP, RTP,,,)?
>
> probably
> Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID
> included...
>
> I tend to agree.
> 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
>
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
t;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
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/
>
gt; 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
> wo
t; 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
?
>
> 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
nsion-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
>
>
>
> _________
ith 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
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
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
: 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
: 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
ransport 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
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 hap
P 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!
&
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:3
, 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
v2 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
>
&g
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
gt; 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 i
ttack 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
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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
shnan
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
Eri
ors. 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.
(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,
>
>
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
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 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
-
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
> 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
t;
> Title : Minimal ESP
> Authors : Daniel Migault
> Tobias Guggemos
> Filename: draft-ietf-lwig-minimal-esp-03.txt
> Pages : 14
> Date: 2021-03-24
>
> Abstra
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
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
1 - 100 of 283 matches
Mail list logo
