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.

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] WGLC of draft-ietf-ipsecme-ikev2-auth-announce

Hi Paul, On Wed, Dec 7, 2022 at 5:46 PM Tero Kivinen < kivi...@iki.fi> wrote: I started this last call almost a month ago, and I have not seen any discussion, comments or emails on the ipsec list. For me that would indicate that nobody has actually reviewed the docume

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 we

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 S

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] 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 that

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] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-02.txt

nouncing 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 all

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] 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 ensur

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, Nu

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 wo

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 g

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] 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] 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 w

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 inste

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 Types &g

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] 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 wi

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-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 "Specific

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 con

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

ed 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 now,

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 t

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

s (IPSECME) 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 > >

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

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

Hi Russ, thank you for your review. Please see inline. > -Original Message- > From: Russ Housley via Datatracker [mailto:nore...@ietf.org] > Sent: Friday, April 14, 2023 3:56 PM > To: sec...@ietf.org > Cc: draft-ietf-ipsecme-g-ikev2@ietf.org; ipsec@ietf.org > Subject: Secdir early rev

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

Action: draft-ietf-ipsecme-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 Ke

[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] [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 u

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

Regards, 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.

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] [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 th

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, > > 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] 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 u

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 in

[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 wra

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

h RFC 9370), and 3. the fact that authentication is > QR (compared to RFC 9370 > alone). The current Security Consideration section is mostly a stub. I agree that more considerations should be added there. Thank you for the concrete proposals. Regards, Valery. > - Rebecca > > Rebecca

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

Hi Paul, > On Wed, 6 Sep 2023, Antony Antony wrote: > > > Here is a proposed text for the I-D. > > > > "Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the > > viability of the path for ESP packets MAY initiate an ESP Echo Request > > I would change this to: > > "After co

Re: [IPsec] [***SPAM***] RE: SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 for your review)

gt; Cheers, > Med > > > -Message d'origine- > > De : Tommy Pauly > > Envoyé : jeudi 5 octobre 2023 04:44 > > À : Paul Wouters > > Cc : BOUCADAIR Mohamed INNOV/NET ; > > ipsec@ietf.org; Valery Smyslov ; ipsecme-...@ietf.org; > > ipsecme-c

Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-ikev2-auth-announce

Hi Tero, thank you for the review. See inline below. > I would need author to reply this email and express whether there is > any IPRs related to this draft known by the authors. I confirm that I'm not aware of any IPR related to this draft. > -- > > In section 3.1 the draft says: > >

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

: Announcing Supported Authentication Methods in IKEv2 >Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-auth-announce-04.txt >Pages: 12 >Dates: 2023-10-16 > > Abstract: > >This specification defines a mechanism that allows the Internet Key

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

t is now available. It is a > work item of the IP Security Maintenance and Extensions (IPSECME) WG of the > IETF. > >Title: Group Key Management using IKEv2 >Authors: Valery Smyslov > Brian Weis >Name:draft-ietf-ipsecme-g-ikev2-10.txt >

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

; To: Valery Smyslov > Subject: New Version Notification for > draft-smyslov-ipsecme-ikev2-qr-alt-09.txt > > A new version of Internet-Draft draft-smyslov-ipsecme-ikev2-qr-alt-09.txt has > been successfully submitted by Valery Smyslov and posted to the > IETF repository. >

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

Hi Roman, thank you for your review, please see inline. > Hi! > > I performed an AD review of draft-ietf-ipsecme-ikev2-auth-announce-04. > Thanks for the work on this > document. I have the following feedback: > > > ** Section 3.1 > If the initiator is configured to use Extensible Authentic

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 > >

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 m

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 codepo

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 send

Re: [IPsec] review draft-ietf-ipsecme-g-ikev2-10.txt

Hi Daniel, thank you for the review. I will look at it a bit later. Regards, Valery. Hi, I reviewed draft-ietf-ipsecme-g-ikev2-10.txt and provides my comments in the attached file. I am providing impressions as I was reading the text, the authors are free to ignore them. I think

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 > str

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 sequence

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 p

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 fo

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 the

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] 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 for

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] GDOI and G-IKEv2 payloads

gt; 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

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

psecme-g-ikev2-11.txt is now available. It is a work item of > the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. > >Title: Group Key Management using IKEv2 >Authors: Valery Smyslov > Brian Weis >Name:draft-ietf-ipsecme-g-ikev2-11.txt &

Re: [IPsec] Artart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

Hi Marc, thank you for your review. > Reviewer: Marc Blanchet > Review result: Ready with Nits > > I'm the assigned ART reviewer for this document. While I'm aware of IPSEC-IKE > and its use, I have no competency in this technology, therefore I have not > verified > the substantive protocol sp

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

Hi Reese, thank you for your review. Please see inline. > Reviewer: Reese Enghardt > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair. Please

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

Hi Rifaat, thank you for your review. Please, see inline. > Reviewer: Rifaat Shekh-Yusef > Review result: Has Issues > > # Section 3.1 > > * The description of the exchange seems odd, as it starts with the responder, > instead of the initiator. I suggest that the description of the exchange >

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

rted Authentication Methods in IKEv2 >Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-auth-announce-07.txt >Pages: 13 >Dates: 2024-04-01 > > Abstract: > >This specification defines a mechanism that allows the Internet Key >Exc

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

Hi Rifaat, I snipped parts where we are in agreement. Hi Valery, See my replies below. Regards, Rifaat […] > * "Since the responder sends the SUPPORTED_AUTH_METHODS notification in > the IKE_SA_INIT exchange, it must take care that the size of the response > message wou

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

Hi Paul, On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: I've added the following sentence to the Introduction: Since IKEv2 doesn't allow to use multiple authentication methods and doesn't provide means for

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

Supported Authentication Methods in IKEv2 >Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-auth-announce-08.txt >Pages: 13 >Dates: 2024-04-02 > > Abstract: > >This specification defines a mechanism that allows the Internet Key >

Re: [IPsec] [***SPAM***] Re: Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

Hi Reese, I snipped most of the text for readability. > Hi Valery, > > Thank you for the response and updates. > > Please see inline: [...] > >> Section 5: > >> > >> "Note, that this is not a real attack, since NULL authentication > >> should be allowed by local security policy." Why is it n

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

> >Title: Announcing Supported Authentication Methods in IKEv2 >Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-auth-announce-09.txt >Pages: 13 >Dates: 2024-04-04 > > Abstract: > >This specification defines a mechanism that all

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

Hi Orie, thank you for your comments, please see inline. > Orie Steele 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 lin

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 comment

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 lin

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&#

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 inta

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] 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] 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. (Fee

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 i

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] 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

[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 t

[IPsec] Re: Clarification questions about Intended behavior draft-ietf-ipsecme-ikev2-qr-alt-00

Hi Vukašin, Hi Valery, While updating the code logic to the latest version of the draft some questions came up to me: 1. Assume the initiator and responder both already support RFC 8784. If the initiator sends USE_PPK_ALT notify, and does not support IKE_INTERMEDIATE exchange, will

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

h for Mixing Preshared Keys in IKEv2 for Post- > quantum Security >Author: Valery Smyslov >Name:draft-ietf-ipsecme-ikev2-qr-alt-01.txt >Pages: 11 >Dates: 2024-07-01 > > Abstract: > >An Internet Key Exchange protocol version 2 (IKEv2) extensi

[IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation availability query

Hi Steffen, Hi Valery, hi Brian, I just wanted to restate my question if you are aware of a potential implementation of G-IKEv2, which is publicly available and which we could use for further investigation regarding extendibility? I found information about a minimal implementation in the

[IPsec] Re: The ESP Echo Protocol document for IPsecME

Hi, thank you for providing use cases in the new version of the draft. I still have some questions about the intended use of the ESP Ping protocol. I understand from the draft that one of the use cases is a manual check for ESP connectivity by network operators. This use case is clear for

[IPsec] Re: draft-smyslov-ipsecme-ikev2-qr-alt update

Hi Paul, as author I fully agree that the document is ready for WGLC. Actually, that's what I said at the meeting. Thank you for repeating this in the ML (it was too late for me to do it myself yesterday). Regards, Valery. > Hi, > > Valery and Vukasin worked on interop testing a few weeks ago o

[IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation availability query

To: Valery Smyslov ; ipsec@ietf.org Subject: RE: [IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation availability query Hi Valery, Thank you for the update. Is there any intention to provide an implementation? Best regards Steffen From: Valery Smyslov mailto:smyslov.i...

[IPsec] Re: Review of draft-ietf-ipsecme-ikev2-qr-alt

Hi Tero, thank you for your review. Please see inline. > When checking whether this document is ready for WGLC I did quick review of > it. > Here are my comments: > > -- > 1. Introduction > ... >[RFC8784] defines an IKEv2

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

lt-02.txt > > Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-02.txt is now available. It is > a work > item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. > >Title: Alternative Approach for Mixing Preshared Keys in IKEv2 for Post- > quantum Sec

<    1   2   3   4   5   6   7   8   9   10   >