Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-07.txt

tories. > This draft is a work item of the IP Security Maintenance and Extensions WG of > the IETF. > > Title : Group Key Management using IKEv2 > Authors : Valery Smyslov > Brian Weis > Filename: draft-ietf-ipsec

[IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance

Hi all, as I promised at the last IETF meeting, this is my review of the draft-pwouters-ipsecme-multi-sa-performance draft. This is not a formal review of the document, but rather some speculations on how the solution may be simplified. Sorry that it took so long and please consider this as an

Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance

Hi Michael, > Valery Smyslov wrote: > > My main problem with the draft is the concept of "Fallback SA". This SA > > is treated specially in the draft, which I don't think is > > necessary. For example, it must always be up so that the outgoing &g

Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

Hi Martin, please see inline. On Mon, Aug 8, 2022 at 5:12 AM Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: > > (Sec 9.1) > "TCP-in-TCP can also lead to "TCP meltdown", where stacked instances >of TCP can result in significant im

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

Hi Paul, thank you for the very thorough review (as usual) :-). Please see inline. > Paul Wouters has entered the following ballot position for > draft-ietf-ipsecme-rfc8229bis-07: Yes > > When responding, please keep the subject line intact and reply to all email > addresses included in the To

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)

Hi Warren, thank you for this discussion, please see inline. > Warren Kumari has entered the following ballot position for > draft-ietf-ipsecme-rfc8229bis-07: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines.

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)

Please see inline. On Wed, Aug 10, 2022 at 4:37 PM, Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: Hi Warren, thank you for this discussion, please see inline. Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-rfc8229bis-07: Di

Re: [IPsec] WGLC of draft-ietf-ipsecme-add-ike

Hi Tommy, thank you for the review and for the proposed changes. I reviewed them and they look good to me. I still disagree with one requested change, see below. From: IPsec On Behalf Of Tommy Pauly Sent: Wednesday, August 10, 2022 7:33 PM To: Tero Kivinen ; ipsec@ietf.org Subject: Re:

Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

Regards, Valery. On Wed, Aug 10, 2022, 01:25 Valery Smyslov mailto:s...@elvis.ru> > wrote: Hi Martin, please see inline. On Mon, Aug 8, 2022 at 5:12 AM Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: > > (Sec 9.1) > "TCP-in-TC

Re: [IPsec] Secdir telechat review of draft-ietf-ipsecme-rfc8229bis-07

Hi Rifaat, thank you for your review. > Reviewer: Rifaat Shekh-Yusef > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit

Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

Hi Martin, thank you for your comments. Please see inline. > Martin Duke has entered the following ballot position for > draft-ietf-ipsecme-rfc8229bis-07: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines.

Re: [IPsec] Erik Kline's No Objection on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

Hi Erik, thank for your comments. Please see inline. > Erik Kline has entered the following ballot position for > draft-ietf-ipsecme-rfc8229bis-07: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

Hi Éric, thank you for your comments. Please see inline. > Éric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-rfc8229bis-07: Yes > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

lot to avoid being biased. > > I agree with all your replies and explanations except when there is EV> > > Regards > > -éric > > > On 09/08/2022, 15:59, "Valery Smyslov" wrote: > > Hi Éric, > > thank you for your comments. Please see in

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-08.txt

F. > > Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Tommy Pauly > Valery Smyslov > Filename: draft-ietf-ipsecme-rfc8229bis-08.txt > Pages : 35 > Date: 2022-

Re: [IPsec] Count-based rekey considerations

Hi Ben, > Hi Valery, > > On Tue, Jul 26, 2022 at 12:04:34PM +0300, Valery Smyslov wrote: > > > > If we assume that we are in Dolev-Yao threat model, then an attacker has no > > access > > to inside the hosts, but it has an unlimited power on the

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

Hi Michael, > > I think it must be pre-configured (just as, for example, using TCP > > encapsulation in IKEv2). Should we add some text? > > If it's an arbitrary port that someone has to configure, then please include > no ports. > > I don't think it should be that way. > > I think

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

Hi Michael, > > Thus, what do you want to see in the third column? "Defined in RFC > > 7296"/"Defined in this document"? > > You could say, "STD79", and "Section X" if you like. I prefer "RFC7296", as it's better known than "STD79" :-) > >> I don't understand GSA_AUTH vs IKE_AUTH.

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

> >> > Thus, what do you want to see in the third column? "Defined in RFC > >> > 7296"/"Defined in this document"? > >> > >> You could say, "STD79", and "Section X" if you like. > > > I prefer "RFC7296", as it's better known than "STD79" :-) > > Yet, it's incorrect. I'm not

Re: [IPsec] Assessing Support for draft-smyslov-ipsecme-ikev2-qr-alt

Hi all, the draft's original goal was to provide a way for G-IKEv2 to make hassle-free use of PPK (in G-IKEv2 sensitive information is transferred at the time the initial IKE SA is created). However, the draft is not tied to G-IKEv2 and can be used with IKEv2 when you need initial IKE

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-02.txt

ing Supported Authentication Methods in IKEv2 > Author : Valery Smyslov > Filename: draft-ietf-ipsecme-ikev2-auth-announce-02.txt > Pages : 10 > Date: 2023-01-10 > > Abstract: >This specification defines a mechanism that allow

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

> > Unless I'm missing something, it's not immediately clear for me how you want > > to use HPKE here. Can you clarify? > > Similar to how MLS is using it to (re)generate the keys for the binary tree. > They addressed the same > problem of having a group and members joining and leaving and

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

Hi Paul, > On Mon, 26 Dec 2022, Valery Smyslov wrote: > > > Subject: Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07 > > I know this comment comes very late, but within the IETF we now see > adoption happening of HPKE, Hybrid Public Key Encryption in RFC 9180. >

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

We are converging :-) > > I'm a bit reluctant to add all this information to the abstract. It is > > already a bit too long > > (since Éric and Warren suggested to augment it with the explanation text of > > how > > this design helps in situation when PQ algorithms are less trusted). So > >

Re: [IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce

Hi Tero, I think the document is ready (but I'm definitely biased here as its author). I also recall, that at the time of document adoption a few people expressed a support for it, so probably they can now look into the current version and say whether it is ready or not. Regards, Valery. >

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

Hi Michael, many thanks for your review. Much appreciated. Please, see inline. > I started reading through this document during IETF115, but didn't finish > until today. I don't think that I have ever read the IKEv1-G stuff. > > > G-IKEv2 SHOULD use UDP port 848, the same as GDOI [RFC6407],

Re: [IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce

Hi Michael, > I am those that didn't read it during WGLC, or pay attention it before, but I > scanned it. > It seems to solve a problem that I don't think that I have. > > I do not object to publishing it. > > Given that Notify messages are available without a draft, it might be that > what

Re: [IPsec] Secdir telechat review of draft-ietf-ipsecme-ikev2-multiple-ke-10

Hi Sean, thank you for your review. Please, see inline. > Reviewer: Sean Turner > Review result: Has Nits > > Hi! Thanks for the well written draft. I really liked Appendix B that includes > the tried but discarded designs. Thank you. > Issue worth discussing (and it might be a short

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Éric, thank you for your comments. Please see inline. > -Original Message- > From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org] > Sent: Tuesday, November 29, 2022 12:38 PM > To: The IESG > Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; >

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

Hi Paul, thank you for your thorough review, please see inline. > -Original Message- > From: Paul Wouters via Datatracker [mailto:nore...@ietf.org] > Sent: Tuesday, November 29, 2022 12:09 AM > To: The IESG > Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; >

Re: [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Warren, thank you for your comments. Please see inline. > -Original Message- > From: Warren Kumari via Datatracker [mailto:nore...@ietf.org] > Sent: Wednesday, November 30, 2022 1:19 AM > To: The IESG > Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; >

Re: [IPsec] Secdir telechat review of draft-ietf-ipsecme-ikev2-multiple-ke-10

Hi Sean, [snipped] > > I'm not sure the DEs have enough qualification to judge whether the proposed > > algorithm is good or bad with its cryptographic properties. I believe it is > > the CFRG's task > > to bless algorithms and the DEs should only pay attention to is whether > > the proposed

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Éric, > Hello Valery, > > TL;DR: Thanks for your reply and your comments. I agree with them ;-) > > If you want a more detailed reply, then look for EV> below OK, I snipped the text where we have an agreement. > Regards > > -éric [snipped] > > The bullet 2) is a nice explanation

Re: [IPsec] Erik Kline's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Erik, thank you for your comments. Please see inline. > -Original Message- > From: Erik Kline via Datatracker [mailto:nore...@ietf.org] > Sent: Wednesday, November 30, 2022 6:16 AM > To: The IESG > Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; >

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Murray, thank you for your comments, please see inline. > -Original Message- > From: Murray Kucherawy via Datatracker [mailto:nore...@ietf.org] > Sent: Thursday, December 01, 2022 10:32 AM > To: The IESG > Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; >

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Éric, > -Original Message- > From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] > Sent: Thursday, December 01, 2022 1:41 PM > To: Valery Smyslov; 'The IESG' > Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; > ipsec@ietf.org; >

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

Hi Paul, let's continue :-) I snipped the text where we are in agreement. > -Original Message- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Tuesday, November 29, 2022 9:49 PM > To: Valery Smyslov > Cc: 'Paul Wouters'; 'The IESG'; > draft-ietf-ipsecme-ikev2-mu

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

HI CJ, From: CJ Tjhai [mailto:c...@post-quantum.com] Sent: Wednesday, November 30, 2022 12:30 PM To: Paul Wouters Cc: Valery Smyslov; Paul Wouters; The IESG; draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; ipsec@ietf.org WG; Tero Kivinen Subject: Re: [IPsec] Paul

Re: [IPsec] IPR Poll RE: Shepherd write-up information for draft-ietf-ipsecme-add-ike

Hi, I confirm that I'm not aware of any IPR related to this draft. Regards, Valery. > Hi all, > > As a input to the writeup, we are replying to the IPR poll on-list. > > I don't have any IPR nor I'm aware of any related to this draft. > > My co-authors replies will follow soon. > > Cheers,

Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

Hi Tero, thank you for the review. Please see inline. > Here are some my review comments while reading > draft-ietf-ipsecme-add-ike: > > -- > The text in section 3.1 should say that if length is 0, then no > Service Priority,

Re: [IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance

HI, I read the document and I support its adoption as a starting point. I'm ready to review and to contribute (we have implemented similar functionality). Regards, Valery. > This is two week working group adoption call for the > draft-pwouters-ipsecme-multi-sa-performance. If you support

Re: [IPsec] IPsecME WG Adoption call for draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt

Hi, I read the document and I support its adoption. I'll be happy to review it. Regards, Valery. > This is two week working roup adoption call for he > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. If you support > adoption of this document to the IPsecME WG send email to the list > before

[IPsec] Do we want to address IKEv2 flaw with cookie processing?

Hi, at the IPSECME@IETF115 I made a presentation (which is actually was also presented at IETF109) about a minor flaw in IKEv2 which is concerned with cookie processing. The flaw becomes noticeable in situation when there is high risk of packet loss and reordering and when the responder either

Re: [IPsec] [saag] IETF 114 IPsecME report

Hi Tero, few comments inline. [a lot of text snipped] > This document should simply say that TS_SECLABEL MUST NOT be used > alone. This document must not try to do incompatible change to the > base RFC7296 which would make conforming implemntations > non-conforming. Unfortunately, this won't

Re: [IPsec] [saag] IETF 114 IPsecME report

Hi Paul, > > The "proper" way would be to introduce new TS types > > TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL. > > I recall that it was already tried before, but I don't remember > > why this way was abandoned. > > The fear of combinatory explosion if something else

Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

> > > Actually is there any point of having ADN Length and Authenticated > > > Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes > > > with certain domain names with different hash algorithms? Perhaps we > > > should define the format for CFG_REQUEST as follows: > > > > > > > >

Re: [IPsec] [IANA #1267827] expert review for draft-ietf-ipsecme-add-ike (ikev2-parameters)

@iki.fi; val...@smyslov.net; ipsec@ietf.org > Subject: [IANA #1267827] expert review for draft-ietf-ipsecme-add-ike > (ikev2-parameters) > > Dear Tero Kivinen and Valery Smyslov (cc: ipsecme WG), > > As the designated experts for the IKEv2 Configuration Payload Attribute Typ

Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09

Hi Tero, > mohamed.boucad...@orange.com writes: > > > But my understanding is that this is not the case here, as if you > > > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with > > > ENCDNS_IP* to implementations supporting old RFC, > > > > [Med] Responders know when it will break. They

Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt

ft is a work item of the IP Security Maintenance and > Extensions WG of the IETF. > > Title : Group Key Management using IKEv2 > Authors : Valery Smyslov > Brian Weis > Filename: draft-ietf-ipsecme-g-ikev2-08.txt >

Re: [IPsec] Disabling replay protection

> > Another approach would be to generalize the Transform Type 5 > > as the way to control the replay protection status > > (see draft-ietf-ipsecme-g-ikev2-07, Section 2.6.) > > I guess that depends on what implementations do when seeing a > Transform Type 5 value with bit 1 set. Would we really

Re: [IPsec] AD review of draft-ietf-ipsecme-add-ike-08

Hi Roman, thank you for the review, please see inline. > Hi > > I performed an AD review of draft-ietf-ipsecme-add-ike-08. Thanks for this > document. Below is my > feedback: > > ** Section 3.1 > > Section 3.1.5 of > [I-D.ietf-add-dnr] lists a set of service parameters that are > recommended

Re: [IPsec] AD review of draft-ietf-ipsecme-add-ike-08

Hi Paul, > > ** Section 3.2. Is the RESERVED field 2 or 3 octets? Figure 2 and 3 says > > two and the text says three. > > I guess two. But a more interesting question is, why are there RESERVED Exactly. > octets there to begin with ? I don't feel this CP payload would get > extended and

Re: [IPsec] Disabling replay protection

Hi, > > Hi IPSECME, > > > > RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is > > employed, the receiver SHOULD > notify the sender, during SA establishment, if the > > receiver will not provide anti-replay protection". > > > > I haven't been able to find any mechanism for this

Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt

HI Daniel, thanks for the follow-up, please see inline (some text is snipped, where we are in agreement). From: Daniel Migault [mailto:mglt.i...@gmail.com] Sent: Friday, April 14, 2023 11:39 PM To: Valery Smyslov Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-g

[IPsec] Use of AEAD algorithms as pure encryption algorithms

Hi, I have a question to the crypto community regarding the use of AEAD algorithms as pure encryption algorithms. The use case is as follows. In G-IKEv2 (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/) we have a situation where keys are transferred inside the G-IKEv2 message. The

Re: [IPsec] Secdir early review of draft-ietf-ipsecme-g-ikev2-08

HI Russ, thank you for the follow-up. Please see inline (I snipped text where we are in agreement). > -Original Message- > From: Russ Housley [mailto:hous...@vigilsec.com] > Sent: Tuesday, April 18, 2023 9:29 PM > To: Valery Smyslov > Cc: IETF SecDir; draft-ietf-

Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-09.txt

psecme-g-ikev2-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the IP Security Maintenance > and Extensions (IPSECME) WG of the IETF. > >Title : Group Key Management using I

Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

Hi Natanael, thank you for your response, please see inline. Den tors 20 apr. 2023 09:42Valery Smyslov < smyslov.i...@gmail.com> skrev: Hi, I have a question to the crypto community regarding the use of AEAD algorithms as pure encryption algorithms. The

Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

Valery. Cheers, John From: CFRG mailto:cfrg-boun...@irtf.org> > on behalf of Valery Smyslov mailto:smyslov.i...@gmail.com> > Date: Friday, 21 April 2023 at 09:44 To: 'Natanael' mailto:natanae...@gmail.com> > Cc: c...@ietf.org <mailto:c...@ietf.org> mailto:c...@i

Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

Hi John, thank you for your comments, please see inline. Hi Valery, Some quick commments. - If the G-IKEv2 engine is not trusted to access information inside the messages, it should probably not be trusted to modify the keys. Chaning the keys would get however is in control of

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-add-ike-11: (with COMMENT)

Hi Éric, thank you for your comments. Please see inline (I will only address some of your comments). > -- > COMMENT: > -- > > Thank you for the work put into

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

Hi Paul, thank you for your comments, please see inline. > Paul Wouters has entered the following ballot position for > draft-ietf-ipsecme-add-ike-11: Discuss > > -- > DISCUSS: >

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt

you please issue an adoption call? Regards, Valery. > -Original Message- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Friday, April 14, 2023 10:32 AM > To: Valery Smyslov > Subject: New Version Notification for > draft-smyslov-ipsecme-i

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-auth-announce-02

HI Paul, > >> There is text about IDi/IDr payloads being used in IKE_INTERMEDIATE and > >> then talk about SHOULD be identical to the ones in IKE_AUTH. I would > >> prefer a > >> different notify for this (eg SAM_IDi/SAM_IDr) to avoid implementers > >> confusing/erroring on confusing these with

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-03.txt

SECME) WG of the IETF. > >Title : Announcing Supported Authentication Methods in IKEv2 >Author : Valery Smyslov >Filename: draft-ietf-ipsecme-ikev2-auth-announce-03.txt >Pages : 11 >Date: 2023-04-14 > > Abstr

Re: [IPsec] draft-ietf-ipsecme-ikev2-multiple-ke new

Hi Panos, Hi draft-ietf-ipsecme-ikev2-multiple-ke authors, ipsecme WG, We have seen attempts to get early codepoints allocated for PQ-hybrid key exchanges in TLS 1.3 and HPKE in other IETF WGs. These, I think, are are good steps. Note for these IANA registries the requirement is

Re: [IPsec] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08

Hi Gorry, thank you for your review. Please see inline. > Reviewer: Gorry Fairhurst > Review result: Ready with Issues > > This is an early review of Group Key Management using IKEv2 concerns transport > issues. It does not comment on the maturity of security aspects, which are the > primary

Re: [IPsec] draft-ietf-ipsecme-ikev2-multiple-ke new

tified and can just serve as the "Specification Required" for the TLS 1.3 IANA registry? From: Valery Smyslov Sent: Tuesday, April 11, 2023 2:53 AM To: Kampanakis, Panos ; draft-ietf-ipsecme-ikev2-multiple...@ietf.org Cc: ipsec@ietf.org Subject: RE: [EXTERNAL]draft-ietf-ipsecme-ikev2

Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08

Hi Gorry, > -Original Message- > From: Gorry Fairhurst [mailto:go...@erg.abdn.ac.uk] > Sent: Tuesday, April 11, 2023 7:22 PM > To: Valery Smyslov; tsv-...@ietf.org > Cc: draft-ietf-ipsecme-g-ikev2@ietf.org; ipsec@ietf.org > Subject: Re: [Tsv-art] Tsvart early re

Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08

[snip] > >>> The packet loss cannot trigger retransmissions, because there is no > >>> back channel from GMs to GCKS. However, there are mechanisms > >>> that allow receiving GMs that miss the next GSA_REKEY message to recover > >>> (see Sections 2.4.1.3 and 4.4.2.2.3). > >> [GF] I understand

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-auth-announce-02

Hi Paul, thank you for this review. > Sorry for the (very) late review. I support the document but have a few > comments and questions. > > The SUPPORTED_AUTH_METHODS NOTIFY is used for multiple purposes. One > of these methods (with no payload data) is used for two different things. > Would it

Re: [IPsec] draft-mglt-ipsecme-ts-dscp

Hi Harold, I have a couple of comments (in addition to the good points made by Scott, which I support). According to RFC 4302 DSCP value is not preserved end-to-end, i.e. intermediate routers are free to re-classify traffic and thus change DSCP. So, the situation is possible, that peers agree

Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

Hi Tobias, > > You do not need to make childless IKE SA mandatory, you simply need to > > do first rekey after initial sa creation using normal rekey, and if > > that normal rekey has SA/KE payloads that are acceptable for the > > optimized rekey in the future, then you can use optimized rekeys

[IPsec] Outstanding issue with G-IKEv2

Hi, before progressing G-IKEv2 draft further, we have to resolve an issue described below. Current spec defines a format for wrapped keys (Section 4.5.1) in such a way, that only confidentiality of the wrapped keys is achieved. The format deliberately omits the integrity protection of the

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

HI Paul, > > Actually, the format is the same for both request and response, > > but depending on Num Hash Algs and AND Length and also on Length, > > some fields may be omitted. > > > The most generic format is: > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >

Re: [IPsec] GDOI and G-IKEv2 payloads

Toerless > > On Tue, Feb 06, 2024 at 10:31:43AM +0300, Valery Smyslov wrote: > > Hi Toerless, > > > > first G-IKEv2 should be published as RFC. The draft is currently in > > WGLC (for a long time), but received very few reviews so far (and many > > thanks to al

Re: [IPsec] GDOI and G-IKEv2 payloads

Hi, Steffen, in general, G-IKEv2 is not backward compatible with GDOI (likewise IKEv2 is not backward compatible with IKEv1). For this reason extensions defined for G-DOI should be redefined for G-IKEv2 (once it becomes an RFC). >From my reading of RFC 8052, it doesn't define new payloads

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-06.txt

>Title: Announcing Supported Authentication Methods in IKEv2 >Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-auth-announce-06.txt >Pages: 13 >Dates: 2023-12-12 > > Abstract: > >This specification defines a mechanism that allows t

Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt

Hi William, thank you for these comments. Please see inline. > Hi, > > I support the adoption of this draft. > I've read the very early version and thought it was quite useful. > I've read it again and still believe it's important and useful. I believe > we're highly likely to implement this >

Re: [IPsec] WG Adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension

Hi, I support adoption of this document and will review it if it is adopted. Regards, Valery. > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen > Sent: Monday, November 27, 2023 9:35 PM > To: ipsec@ietf.org > Subject: [IPsec] WG Adoption call

Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt

HI, I support adoption of this document (I am its author). We also have implemented it. Regards, Valery. > This is two week adoption call for draft-smyslov-ipsecme-ikev2-qr-alt. > If you support adopting this document as a working group document for > IPsecME to work on, and then at some point

Re: [IPsec] GDOI and G-IKEv2 payloads

Hi Toerless, first G-IKEv2 should be published as RFC. The draft is currently in WGLC (for a long time), but received very few reviews so far (and many thanks to all who reviewed it!). I'm planning to publish an updated version addressing Daniel's review soon. Once G-IKEv2 is standardized, there

Re: [IPsec] Interesting attacks on PKCS#v1.5 in IKE

Hi, > > - Maybe look at a new EAP method to prevent AUTH payload from the > >server to be send before client is authenticated. If EAP is employed the server sends AUTH twice - first time before any EAP method starts and second time - at the end of EAP protocol. Are you suggesting not to

Re: [IPsec] Interesting attacks on PKCS#v1.5 in IKE

Hi Paul, > >> On the other perhaps we should think of moving Secure Password > >> Framework for IKev2 (RFC6467) and ONE of the associated password > >> authentication methods to standard track, > > > > Strongly support. > > We also talked about that before. A truly strong random PSK is much >

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

Hi Paul, I snipped parts where we are in agreement. > > 2. Section 2 > > > > There are a number of practical reasons why most Implementations have > > to limit a Child SA to only one specific hardware resource, but a key > > limitation is that sharing the crypto state, counters and

Re: [IPsec] New Version Notification for draft-kampanakis-ml-kem-ikev2-00.txt

Hi Panos, first, thank you for posting this draft. I think this is an important work. Few comments below. First, you should not use in the draft any codepoints until IANA allocates them. Just replace your self-allocated values for ML-KEM with "" whenever it is mentioned in the draft. Once

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

Hi, I support publication of this draft. I'm glad authors took my points into consideration while preparing the latest version. I do have some comments though. 1. Section 1 IKEv2 [RFC7296] already allows installing multiple Child SAs with identical Traffic Selectors, but it offers no

Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04

HI Roman! > Hi Valery! > > Thanks for -05. Reducing the thread down to areas of discussion. > > > -Original Message- > > From: Valery Smyslov > > Sent: Thursday, October 26, 2023 11:51 AM > > To: 'Roman Danyliw' ; ipsec@ietf.org > > Subject: R

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi Éric, thank you for your comments, please see inline. > Éric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

:56 AM, Valery Smyslov mailto:s...@elvis.ru> > wrote: Hi Mahesh, thank you for your comments, please see inline. Mahesh Jethanandani has entered the following ballot position for draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection When responding, please keep the subject line

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi Éric, please see inline. Thank you, Valery, for the prompt reply. See below for EVY> Regards -éric From: Valery Smyslov mailto:s...@elvis.ru> > Date: Thursday, 11 April 2024 at 15:23 To: Eric Vyncke (evyncke) mailto:evyn...@cisco.com> >, 'The IESG' mailt

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-00.txt

Preshared Keys in IKEv2 for Post- > quantum Security >Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-qr-alt-00.txt >Pages: 11 >Dates: 2024-04-12 > > Abstract: > >An Internet Key Exchange protocol version 2 (IKEv2) extension defined >

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi Murray, > Murray Kucherawy has entered the following ballot position for > draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory >

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi Paul, > >> Note that the IANA registry involved here was renamed since the > >> latest draft was written :) > >> > >> Notify Message Type -> Notify Message Status Type > >> > >> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message > >> Status Type > > > > This is already fixed

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-10.txt

>Title: Announcing Supported Authentication Methods in IKEv2 > Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-auth-announce-10.txt >Pages: 14 >Dates: 2024-04-18 > > Abstract: > >This specification defines a mechanism that allows the Inte

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi Éric, please see inline (I removed parts of the message where we are in agreement). Thank you, Valery, for your 2nd reply and for allowing me to reply w/o on-line access to the I-D when I replied. One last comment below as EVY2> All comments were non-blocking anyway :) -éric

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi Mahesh, thank you for your comments, please see inline. > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi, for some reason I didn't receive a message with comments from Gunter, but I noticed his comments at the ballot page (it seems that the e-mail wasn't requested to be sent, as indicated in the datatracker). I'm not sure if the message will be sent later and I want to respond to these

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

HI Paul, thank you for your comments, please see inline. > Paul Wouters has entered the following ballot position for > draft-ietf-ipsecme-ikev2-auth-announce-09: Yes > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines.

[IPsec] Review of draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt

Hi, I reviewed draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt. The document is in a good shape, however it has some issues that need to be fixed. 1. Section 3. To indicate support for the optimized rekey negotiation, the initiator includes the OPTIMIZED_REKEY_SUPPORTED notify payload in

<    3   4   5   6   7   8   9   >