[IPsec] IPsec multihoming and mobility

-00 Protocol Design : http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 We are currently working implementing it, and looking on how other multihoming protocol can benefit from it. Feed backs and comments are really appreciated. Regards, Daniel -- Daniel Migault Orange Labs

Re: [IPsec] WESP - Roadmap Ahead

dont have to provide support for AH. AH is a security feature we need to keep for header authentication. Other WG may chose not to deal with AH and only consider ESP. I don't see what's wrong with that? Regards Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] Childless IKE SA

-author. Thanks, -Amjad ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org

Re: [IPsec] Proposed work item: IKE/IPsec high availability and load sharing

time to work on it. I might read a WG FC, and I might respond to threads, if I came across them. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] Traffic visibility - consensus call

this design decision. Regards, Daniel Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-00.txt

/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] SPI Collision

. INVALID_SPI does not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE packet comes with an unrecognized SPI. In addition it seems the Notify Payload MUST be sent out of the IKE_SA Can anyone tell me which error message is used? BR Daniel -- Daniel Migault Orange Labs -- Security

Re: [IPsec] SPI Collision

Hi Yoav, Thank you very much for your answer. It does fully answer my question! BR, Daniel On Thu, Apr 5, 2012 at 9:15 PM, Yoav Nir y...@checkpoint.com wrote: Hi Daniel On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote: Hi, I am wondering how SPI collision is considered by IKEv2

[IPsec] Fwd: New Version Notification for draft-mglt-mif-security-requirements-02.txt

-security-requirements-02.txt To: mglt.i...@gmail.com Cc: ca...@mcsr-labs.org A new version of I-D, draft-mglt-mif-security-requirements-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename:draft-mglt-mif-security-requirements Revision

Re: [IPsec] New Version Notification for draft-mglt-mif-security-requirements-02.txt

Hi, We will be presenting MIF security requirements for IPsec at the mif meeting at 1pm. If you have free time, we would appreciate you come and participate in the discussion. BR, Daniel On Mon, Jul 30, 2012 at 6:59 AM, Daniel Migault mglt.i...@gmail.com wrote: Please find the new version

Re: [IPsec] Call for agenda items

___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Pre-meeting reading

-- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Preliminary minutes from today's meeting

comment that the draft should support different types of groups we have out there. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] IPsecME virtual meeting minutes, and way forward with fragmentation

yes, that was me. Daniel On 05/17/2013 10:08 AM, Yoav Nir wrote: On May 17, 2013, at 2:54 AM, Brian Weis b...@cisco.com wrote: [snip] Yaron: do we want to stay with the current TCP-based solution? Brian: might be running on sensors that don't have a TCP stack Someone made this

[IPsec] IPsec and multiple interfaces: draft-mglt-ipsecme-keep-old-ike-sa-00.txt

-old-ike-sa-00.txt Best Regards, Daniel -- Forwarded message -- From: internet-dra...@ietf.org Date: Fri, Jul 5, 2013 at 12:15 PM Subject: New Version Notification for draft-mglt-ipsecme-keep-old-ike-sa-00. txt To: Daniel Migault mglt.i...@gmail.com A new version of I-D, draft-mglt

Re: [IPsec] Some comments on draft-mglt-ipsecme-keep-old-ike-sa-00

-- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP

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, We have not updated the draft to change their names, but I agree they definitely better fit

Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP

deployments. Ciao Hannes On 01/31/2014 02:48 PM, Daniel Migault wrote: Hi, Please find the two drafts we have just posted. They are about IPsec/ESP minimal implementation and Diet-ESP designed for IoT. Comment are welcome! Best Regards, Daniel Name:draft-mglt-dice-diet-esp Revision

Re: [IPsec] Draft: IKEv2/IPsec Context Definition

and Regards, Yogendra Pal +919686202644 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing

Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03

Hi, Thanks for the feed back, please see inline my response. BR, Daniel On Thu, Feb 6, 2014 at 11:07 AM, Timo Teras timo.te...@iki.fi wrote: On Thu, 6 Feb 2014 09:20:08 +0100 Daniel Migault mglt.i...@gmail.com wrote: Thanks for the feed back. We are happy you provide requirements over

Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP

that, for the energy cost of exchanging 1 bit, our system can alternatively compute 10-100 instructions. Regards, Valery Smyslov. Best Regards, Daniel - Original Message - From: Yaron Sheffer yaronf.i...@gmail.com To: Daniel Migault mglt.i...@gmail.com; Hannes Tschofenig

Re: [IPsec] Draft: IKEv2/IPsec Context Definition

with the security issues resulting from this behavior. So a node would be sharing more than it bargained for. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs

Re: [IPsec] ChaCha20 Poly1305, AEAD and other modes

for performance, especially on non-Intel platforms. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01

___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman

[IPsec] Fwd: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt

, Daniel Migault daniel.miga...@orange.com, Daniel Migault daniel.miga...@orange.com A new version of I-D, draft-mglt-ipsecme-clone-ike-sa-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-clone-ike-sa Revision: 01 Title: Clone IKE SA

[IPsec] Fwd: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt

-- Forwarded message -- From: Daniel Migault mglt.i...@gmail.com Date: Thu, Mar 13, 2014 at 9:51 AM Subject: Fwd: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt To: ipsec@ietf.org ipsec@ietf.org Cc: Valery Smyslov sva...@gmail.com Hi, Please find the new version

Re: [IPsec] Any reason to meet in Toronto?

___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman

[IPsec] draft-mglt-lwig-minimal-esp-01.txt

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 72 69 58

[IPsec] Diet-ESP

-esp-requirements/ [2] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ [3] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-iv-generation/ [4] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-payload-compression/ -- Daniel Migault Orange Labs -- Security +33 6 70

Re: [IPsec] draft-mglt-ipsecme-diet-esp-iv-generation

defining new transorms (for example AES-CBC with implicit IV) instead of negotiating IV compression separately. That is maybe the way to do. Thanks for your feed back. Regards, Valery Smyslov. -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] Charter update

on standarising fragmentation support using UDP. Paul OK, makes sense. We need to remove that sentence. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security

[IPsec] IP Security for multiple interfaces

this topic is of interests and should be addressed - 2) if you would like to review the documents Comments on the draft are also welcome! BR, Daniel [1] http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-02 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] Diet-ESP

___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Diet-ESP

. Motivation for doing so is that sending a byte in 6lo cost more than doing a few thousand operations. In that sense, we are ready to implement some more complex IV-to-i function. Isn't the lo in 6lo, low power? Is it clear that the cycles vs. bandwidth tradeoff is always a win? Steve -- Daniel

Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol

-- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode

end up with some kind of spec, than I would rather not see adoption now. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58

Re: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa

-- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Diet-ESP

for security. I agree. I think it would be very useful to describe a barebones minimal IKEv2 feature set and even an ESP minimal set for such use, but tweaking a byte here and there of the ESP protocol parameters makes we very nervous. Paul -- Daniel Migault Ericsson

Re: [IPsec] Diet-ESP

those tiny ICVs – those won’t make a poor situation even worse. *From:* Daniel Migault [mailto:mglt.i...@gmail.com] *Sent:* Tuesday, February 17, 2015 10:48 AM *To:* Scott Fluhrer (sfluhrer) *Cc:* 6...@ietf.org; ipsec@ietf.org *Subject:* Re: [IPsec] Diet-ESP Hi Scott, Thank you

Re: [IPsec] Diet-ESP

Hi Paul, I click send too quickly. I agree that providing the minimal description for ESP and IKEv2 is useful, however Diet-ESP and minimal implementations have different goals. BR, Daniel On Wed, Feb 18, 2015 at 5:08 AM, Daniel Migault mglt.i...@gmail.com wrote: Hi Paul, The bare minimal

Re: [IPsec] Diet-ESP

internally). Oh, and a minor note on the IV generation: it’s actually secure to use the same key you use to encrypt to encrypt the counter for the IV; you don’t need a separate key. *From:* IPsec [mailto:ipsec-boun...@ietf.org] *On Behalf Of *Daniel Migault *Sent:* Monday, February 16

[IPsec] Diet-ESP

, Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa

Hi, Thank you Tero for providing these explanation, We would like to update the current draft with additional text on SA duplication and its associated issues raised by Paul. We believe it would also help to position/understand Clone IKE SA. The text is expected to be added in the introduction.

Re: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer)

Hi, Thank you for taking time to review the document and raising the issues. We noticed they have remained unanswered yet, -- although your points have probably helped us clarifying the document. This email's intention is to address the issue you raised. Feel free to let us know whether you agree

[IPsec] FW: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-05.txt

/y0oklrJ_HYmbX07lDrbF0fqdEss -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Monday, August 24, 2015 8:13 AM To: Valery Smyslov; Valery Smyslov; Daniel Migault; Daniel Migault Subject: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-05.txt A new

Re: [IPsec] RFC 4307bis

Hi, You can view the latest changes here: https://github.com/mglt /drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme -rfc4307bis We added some text to recommend the status of each recommended algorithms. On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman

[IPsec] RFC4307bis -- 3GPP inputs

Hi, 3GPP is also looking at updating its IKEv2 profile - most likely in November. I beleive it would be good to know about it and eventually to position RFC4307bis toward them. So far the differences I see with [1] are: - DH group 19 (256-bit random ECP group) is MUST in 3GPP instead of

Re: [IPsec] RFC4307bis -- 3GPP inputs

. This will be useful for everyone, including other communities to make their own choice according to their own specifies. BR, Daniel -Original Message- From: Paul Wouters [mailto:p...@nohats.ca] Sent: Tuesday, October 13, 2015 5:13 PM To: Daniel Migault Cc: Tero Kivinen; IPsecME WG; Yoav

Re: [IPsec] RFC4307 update

Hi, Here are my comments on the draft: I would thought: AES_CBC is no more than MUST- for interoperability but could be dowgraded also to SHOULD. In addition I would also have recommend max length IV for AES-GCM unless there is special constrains like IoT devices. AES-GCM with a 16 octet ICV

Re: [IPsec] RFC4307 update

Hi, There is a need to have that kind of document for 3GPP/SA3. Unless someone has already written the update, I can provide one by the end of the week. BR, Daniel -Original Message- From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Michael Richardson Sent: Monday,

Re: [IPsec] RFC 4307bis

, Dec 2, 2015 at 4:01 PM, Daniel Migault <daniel.miga...@ericsson.com> wrote: > Hi, > > Please se the current version of the document with the subsection in the > Introduction. > > > https://github.com/mglt/drafts/commit/ef72ea482af74d4226d3059237024f63d0add01b > &

Re: [IPsec] RFC 4307bis

, Daniel Migault < daniel.miga...@ericsson.com> wrote: > Hi Tommy, > > Thanks for the proposition Tommy, I thnik that will clearer to have > dedicated subsections in the intro. Here are the subsection I would > propose. I am waiting for the WG feed back before updating the draft, so

Re: [IPsec] RFC4307bis and authentication methods

Hi, I have the impression the recommendation goes beyond the scope of IKEv2 and is more targeting Certificates. On the other hand, having these requirements would make all cryptographic requirements fit into a single document IKEv2 As a result, I would rather have a section with a link to a

Re: [IPsec] RFC 4307bis

Hi Paul and Tommy, Please find the new update of the draft: 1) text in the introduction has been added to specify the IoT use case, and the motivations for having IoT considerations in this document. 2) IoT has been indicated in the tables with a comment specifying that the requirement is for IoT

Re: [IPsec] RFC 4307bis

is relevant, explaining deprecation of algorithms, and the > IoT section. > > Thanks, > tommy > > On Nov 26, 2015, at 2:58 PM, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > Hi Paul and Tommy, > > Please find the new update of the draf

Re: [IPsec] RFC 4307bis

of the subsections have also been updated to better fit IANA designation. Change 3: Sections have been re-ordered so from Typpe 1 / Type 3 / Type 2 / Type 4 to Type 1/ Type 2/ Type 3 / Type 4. Feel free to comment. BR, Daniel On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault <daniel.m

Re: [IPsec] RFC 4307bis

s do not > include > > Thanks, > Yaron > > > On 11/16/2015 06:05 PM, Daniel Migault wrote: > >> Hi, >> >> Thank you Yaron for your comments. Please find the new update ot the >> draft: >> >> >> https://github.com/mglt/drafts/commi

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

e 09, 2016 12:12 PM To: Tobias Guggemos; Yoav Nir; Daniel Migault Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Hi Yaron, Thanks Yaron for the comments so I updated my local copy replacing RFC4104 by RFC4106 ;-) I also assume that leaving AES-CTR is fine, and so keep it in the draft. In the first version of the draft we described a way to have an implicit IV with AES-CBC. It was based on an additional key

Re: [IPsec] New Version Notification fordraft-mglt-ipsecme-implicit-iv-00.txt

> > > These two options are similar in terms of complexity. > I slightly prefer new Transform IDs over an Implicit IV Attribute since > in this case it is very clear from the IANA registry which ciphers > can be used with Implicit IV. > > Regards, > Valery. > > > [1

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Hi Tero, Thank you for the feed back, my understanding is that we have a a consensus that Transform ID is the preferred way. I will update the draft accordingly and post a new version next week. BR, Daniel On Fri, Jun 17, 2016 at 9:41 AM, Tero Kivinen <kivi...@iki.fi> wrote: > Danie

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

parsing. This is something that is not widely used outside key sizes. This solution might be preferred if it is considered a better architecture design than b). BR, Daniel On Wed, Jun 15, 2016 at 4:14 PM, Daniel Migault <daniel.miga...@ericsson.com > wrote: > Hi Yaron, &

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Daniel > > I think since we didn’t go with some of the wild ideas that would allow > implicit IV in CBC, the verb “compute” here is somewhat confusing. We’re > pretty much just copying the sequence number. “Compute” implies something a > bit more CPU intensive. > > Yoav > &g

Re: [IPsec] meeting at IETF-95 ?

+1 On Wed, Jan 13, 2016 at 10:10 AM, Valery Smyslov wrote: > Count me too. > > Regards, > Valery. > > > +1 to having a meeting at IETF 95. >> >> Thanks, >> Tommy >> >> On Jan 12, 2016, at 6:56 AM, Paul Wouters wrote: >>> >>> >>> I hope we are scheduling a

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

Hi everyone, I would also be more than happy to present our ongoing work on IKEv2/YANG. BR Daniel On Fri, Mar 11, 2016 at 12:55 PM, Paul Wouters wrote: > On Thu, 10 Mar 2016, Paul Hoffman wrote: > > >> https: //www.ietf.org/proceedings/95/agenda/agenda-95-ipsecme >> >>

Re: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

Hi Paul, I leave my co-authors to respond on the YANG aspects. Regarding the initial-retransmission-timeout I think we meant a time in second. Do you think we need more options? BR, Daniel On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters <p...@nohats.ca> wrote: > On Sun, 27 Mar 201

Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

:04, Daniel Migault <daniel.miga...@ericsson.com> escribió: Hi, Please find our first version for the YANG model for IKEv2. Feel free to post comments. I would be also happy to have face-to-face discussions on the draft - especially from IKEv2 implementers. BR, Daniel -Original M

[IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

...@ietf.org] Sent: Friday, March 18, 2016 11:01 AM To: Xia Chen; Honglei Wang; Khanh Tran; Khanh Tran; Vijay Kumar Nagaraj; Daniel Migault Subject: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt has been successfully

Re: [IPsec] Proposed wording for a revised charter

On Fri, Mar 4, 2016 at 5:05 PM, Tommy Pauly wrote: > I would also like to see the draft for TCP encapsulation added as an item, > since we’ve gotten a fair amount of support for it. I am supporting this item. > For the purposes of the charter, it may be good to have a

Re: [IPsec] Proposed wording for a revised charter

Hi, We would like to add the definition of YANG models for IKEv2 and IPsec as items of the charter. The intent of such models is to be able to provide configurations that are implementations independent. Of course IPsecme will be expected to provide feed backs/comments on the data model which

[IPsec] Phone found in the ipsecme meeting room

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

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

t; > On May 6, 2016, at 4:48 PM, Paul Wouters <p...@nohats.ca> wrote: > > > > On Fri, 6 May 2016, Daniel Migault wrote: > > > >> s/IPSec/IPsec > > > > If Tommy could also fix that auto-correct for my iphone, that would be > > great too :) > &g

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

Hi, I have read the draft. TCP encapsulation is a topic that matters, and I would like different vendors to implement a standard version of this. I think the draft is in good shape to be adopted and discussed as a WG document. I am volunteering to continue reviewing the draft and contribute to

[IPsec] review for draft-ietf-ipsecme-tcp-encaps-01

Hi, I reviewed draft-ietf-ipsecme-tcp-encaps-01 as my understanding is that we are doing a pre-WGLC. I think the draft is in pretty good shape for a WGLC. Please see my comments below. BR, Daniel TCP Encapsulation of IKE and IPSec Packets

Re: [IPsec] Chairs

Thanks Paul David and Tero for serving ipsecme WG ! On Tue, May 31, 2016 at 11:14 AM, Paul Wouters wrote: > On Tue, 31 May 2016, Kathleen Moriarty wrote: > > I'd like to thank Paul for his many years chairing IPSecMe! We look >> forward to your continued participation. >> >>

Re: [IPsec] IETF 96 IPsecME Agenda

Hi David, We should be presenting Diet-ESP in 6lo and mostly presenting the use cases, so we might also willing to have a short update on Diet-ESP in ipsecme. I could also do that shortly in Berlin. Yang model drafts have not been updated since BA, so I do not think we are ready yet to present

Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document

Apology for the late support, - but I already mentioned my support for the draft adoption. I will review the document. BR, Daniel On Mon, Jun 6, 2016 at 11:03 PM, Samy Touati wrote: > Hi, > > I do support the adoption of this draft by the WG. > Ericsson is

Re: [IPsec] IETF 96 IPsecME Agenda

Please also add:draft-mglt-ipsecme-implicit-iv. I (or Yoav) can also present about draft-mglt-ipsecme-implicit-iv. In addition draft-mglt-ipsecme-rfc7321bis can be

Re: [IPsec] Call for adoption of draft-pauly-ipsecme-split-dns as an IPSecME WG document

I support the adoption of this draft. I have reviewed the draft and believe it is in good shape. I am ready for more reviews. Yours Daniel On Jan 30, 2017 15:59, "Waltermire, David A. (Fed)" < david.walterm...@nist.gov> wrote: This is the call for adoption of https://datatracker.ietf.org/

[IPsec] FW: New Version Notification for draft-mglt-ipsecme-implicit-iv-01.txt

- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Saturday, October 08, 2016 7:15 PM To: Tobias Guggemos <tobias.gugge...@gmail.com>; Yoav Nir <ynir.i...@gmail.com>; Daniel Migault <daniel.miga...@ericsson.com> Subject: New Version Notification for draft-mglt-i

Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt

gt; >> BR, >> Daniel >> >> -Original Message- >> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] >> Sent: Saturday, October 08, 2016 7:15 PM >> To: Tobias Guggemos <tobias.gugge...@gmail.com>; Yoav Nir < >> ynir.

[IPsec] FW: New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt

- Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Gesendet: Mittwoch, 12. Oktober 2016 19:45 An: Carsten Bormann <c...@tzi.org>; Daniel Migault <daniel.miga...@ericsson.com>; Tobias Guggemos <gugge...@mnm-team.org> Betreff: New Version Notification for draft-mglt-i

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

i would like the same policy - context or no context - applied to both EdDSA algo. ctx prevents cross protocol attacks but may encourage bad practice. Yours, Daniel On Nov 16, 2016 1:35 PM, "Yaron Sheffer" wrote: On 16/11/16 12:41, Paul Wouters wrote: > > > On Nov 16,

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

n Sheffer <yaronf.i...@gmail.com> wrote: >> >> If you mean the same policy for IPsec and TLS, I fully agree. >> >> Context prevents cross-protocol attacks, and I wouldn't worry about "encouraging bad behavior". Users will behave badly whether we encourage them

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

In fact is there anyone opposing their status becomes MUST NOT in rfc4307bis. On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson wrote: > > I'm proposing it is time to change this to MUST NOT for 4307bis. > > > > +1 > > On 09/10/16 23:26, "IPsec on behalf of Paul

Re: [IPsec] New Version of Split DNS for IKEv2

Hi, Please find my comments on draft-pauly-ipsecme-split-dns-02. Yours, Daniel 3. Protocol Exchange 3.1. Configuration Request An initiator MAY convey its current DNSSEC trust anchors for the domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does not wish to convey

Re: [IPsec] Number of fixed SPI

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 <daniel.m

[IPsec] Number of fixed SPI

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 <daniel.miga...@ericsson.com > wrote: > Hi, > > Please find an update of a guidance for light implementation of standard &

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

escorla <e...@rtfm.com> wrote: > I think Yoav's suggestion to cite BEAST as evidence that predictable IVs > are bad is a good plan. > > -Ekr > > > On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault < > daniel.miga...@ericsson.com> wrote: > >> Hi Eric, >&g

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

Hi Eric, Thank you for the review and comments. Do you have any preference on what we should cite for the chosen clear text attack?: Our local version currently refers to Security Consideration of RFC3602. The sentence in the terminology section mentioning that IV are usually unpredictable has

Re: [IPsec] [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt

Hi, Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. Yours, Daniel -Original Message- From: Curdle

Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv

Hi, I am also supporting the draft as a co-author. Yours, Daniel On Wed, Mar 29, 2017 at 5:03 PM, David Schinazi wrote: > Hello all, > > I strongly support adoption of this document. > I have read it and implemented it. > The document reads well, and allows independent

Re: [IPsec] [Lwip] Number of fixed SPI

to a limited number of SPI are on the node side.Thanks! On Sun, Mar 26, 2017 at 1:45 PM, Tero Kivinen <kivi...@iki.fi> 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

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

S 2. >This document does not consider AES-CBC ([RFC3602])as AES-CBC >>requires the IV to be unpredictable. Deriving it directly from the >>packet counter as described below is insecure. >> >> Can you provide a cite for this? >> >> >> Even RFC 3602 requires that the IV be randomly

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

Regarding the first item manual key is prevented by AES-GCM RFC4306. We do not not such "MUST NOT" level for AES-CCM and Chacha20_poly1305. Maybe we could relax that a little bit and be more accurate saying: OLD: " If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM,

Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

Hi Alissa, Thanks you for the review and the comments. The recommendation is mostly here for implementation that needs to consider interoperability with IoT devices. This includes the IoT devices themselves. So I have replaced "IoT interoperability" with "to interoperate with IoT devices". Happy

[IPsec] FW: New Version Notification for draft-mglt-lwig-minimal-esp-04.txt

org>; Daniel Migault <daniel.miga...@ericsson.com> Subject: New Version Notification for draft-mglt-lwig-minimal-esp-04.txt A new version of I-D, draft-mglt-lwig-minimal-esp-04.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: dra

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

some push-back, I will submit this right before the deadline. > > Yoav > > On 8 Mar 2017, at 20:49, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > Hi, > > Please find my comments regarding the draft. I believe the draft is ready > to be moved forwa

Re: [IPsec] Preference of ESP over AH in RFC7321bis question.

Hi Dang, My understanding is that the usage of AH vs ESP is outside the scope of recommendations mandatory to implement cryptography. It is mostly a usage concern. In my view AH and ESP are both mandatory to be implemented and RFC7321bis limits its scope to the crypto recommendations. Do you

  1   2   3   >