: 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,
&g
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:*
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 req
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
ing 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 o
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 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]
>>
>> > I
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 re
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
ket)
> > 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.
> >
>
MPs 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
ed 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 wr
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 ICM
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 rou
> 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:* Harol
> --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
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
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
> > wo
re 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/
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
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
ield Codepoints " (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 pac
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, Daniel Mi
:
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 M
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
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 impor
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/mai
ndelman 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
ing 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
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
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
&g
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
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 exch
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
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 change
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
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
s (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
tocol"? 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
ull 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
> 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 at 11:14 A
gt;
>
>
> 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
>
>
>
> _______
>
> 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
>
--
Dan
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
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
nsport 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
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 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
&g
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
, 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
2 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
>
> __
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
:
>
> 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 resour
ey.
>
> 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,
&g
ed 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
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
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
;* 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
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
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 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
ome 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
ime, 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
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
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
>
>
>
>
1 - 100 of 262 matches
Mail list logo
