Re: [IPsec] Count-based rekey considerations

Hi Valery, On Mon, Aug 01, 2022 at 12:45:59PM +0300, Valery Smyslov wrote: > 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

Re: [IPsec] Count-based rekey considerations

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 network. Generally > speaking > with this model the most sensible

Re: [IPsec] Transport ESP and SCHC

On Tue, Apr 19, 2022 at 11:09:26PM -0400, Robert Moskowitz wrote: > Has there been any discussion about Transport ESP and SCHC from lpwan? > > https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/ > > In Sec 5, the assumption is the security envelope is above UDP. e.g. > DTLS and

Re: [IPsec] Agenda for IPsecME @ IETF#113

I can take the blame for that. I started doing my AD review of all three together, but it got preempted by some combination of $dayjob and IESG telechats. I'm trying to prioritize clearing pending DISCUSSes in the first half of this week, as there's something of a deadline for them, but hope to

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

On Wed, Feb 02, 2022 at 06:19:56PM +0300, Valery Smyslov wrote: > Hi, > > I've published a new version of the draft. It addresses concerns raised > during AD review. Thanks, Valery -- these look good! [...] > Since the authentication scheme is changed, I'm not sure whether another WGLC > is

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07

Hi Valery, Trimming as appropriate... On Tue, Jan 11, 2022 at 05:55:45PM +0300, Valery Smyslov wrote: > > > Section 3.3.2 > > > >The requirement to support this behavior makes authentication > >challenging: it is not appropriate to add on-the-wire content of the > >IKE_INTERMEDIATE

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07

Hi Tero, On Tue, Jan 11, 2022 at 02:22:53PM +0200, Tero Kivinen wrote: > Benjamin Kaduk writes: > > I'd also like to confirm that the current (lack of) Updates: > > relationship between this document and RFC 7296 is correct. In §3.2, we > > reaffirm that the normal IK

[IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07

Hi all, The core mechanisms here seem in good shape. My main area of uncertainty relates to how much analysis, and with what degree of formalism, has been applied to the updated IKE_AUTH procedures that are supposed to authenticate the intermediate exchange(s). My comments on §3.3.2 have more

Re: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt

On Fri, Nov 12, 2021 at 10:05:05AM -0500, Lou Berger wrote: > Hi Tero, > > You said: > > On 11/9/2021 5:11 AM, Tero Kivinen wrote: > > I think there is still bit of tweaking that can be done, > > Is this tweak being made as a blocking comment by the document Shepherd > or a non-blocking

Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec

On Tue, Jul 27, 2021 at 11:16:36PM -0400, Paul Wouters wrote: > On Tue, 27 Jul 2021, Tero Kivinen wrote: > > > This is the start of 2 week WGLC on the > > draft-ietf-ipsecme-labeled-ipsec document, ending 2021-08-10. > > > > Please submit your comments to the list, also send a note if you have >

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

On Mon, Jun 28, 2021 at 11:23:32AM +0300, Valery Smyslov wrote: [...] > > - The draft currently has all its references as Normative. >I have no problems with this (except that RFC 3740 is Informational, >so should not be referenced as Normative in Standards Track and BCP > documents, >

Re: [IPsec] ipsecme not meeting @ IETF 111?

On Tue, Jun 29, 2021 at 01:26:00AM +0300, Tero Kivinen wrote: > Christian Hopps writes: > > > On Jun 27, 2021, at 10:30 AM, Paul Wouters wrote: > > >> On Jun 27, 2021, at 05:04, Christian Hopps wrote: > > >> I don’t see ipsecme scheduled at IETF 111, is there no meeting? > > I was too busy

Re: [IPsec] [Technical Errata Reported] RFC8031 (6339)

Can anyone speak to the history of the examples here (or the content of the report itself)? Thanks, Ben On Tue, Nov 17, 2020 at 10:46:21AM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC8031, > "Curve25519 and Curve448 for the Internet Key Exchange

Re: [IPsec] AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04

> > Please see inline. > > Cheers, > Med > > > -----Message d'origine- > > De : Benjamin Kaduk [mailto:ka...@mit.edu] > > Envoyé : mardi 20 octobre 2020 21:56 > > À : draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org > > Cc : ipsec@ietf.

[IPsec] AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04

Hi Med, Not a whole lot to comment on here, but probably we should publish a new revisionn to tidy things up before asking for IETF LC. Thanks, Ben % We use the term "dual-stack" several times but it is not defined

Re: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-01.txt

On Fri, Sep 18, 2020 at 03:51:11PM +0300, Valery Smyslov wrote: > Hi Paul, > > > Why is this using a seperate CP payload type per encrypted DNS type? > > This means that for a DNS server supporting DoT, DoH and DoQ, it needs > > to send 3 separate payloads. Why not send 1 CP payload that contains

Re: [IPsec] Question on RFC 5723 Session Resumption

On Sun, Aug 30, 2020 at 10:42:07PM -0400, Paul Wouters wrote: > On Mon, 31 Aug 2020, Tero Kivinen wrote: > > > That should not matter, the server should not invalidate tickets even > > if there is liveness failures, as if it does that every time there is > > transient network failure the

Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting

Hi Med, Yoav, all, On Wed, Jul 29, 2020 at 05:38:17AM +, mohamed.boucad...@orange.com wrote: > Hi Yoav, Ben, all, > > == > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, > for DoH, need to provide URI template FWIW, the first point was not quite "belongs in

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

On Sun, Jun 21, 2020 at 11:37:58PM -0400, Paul Wouters wrote: > On Jun 21, 2020, at 22:22, Toerless Eckert wrote: > > > > Thanks, Valery > > > > let me pick up the one point i have no clear text solution for yet. > > > >> On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote: > >> Hi

Re: [IPsec] draft-ietf-ipsecme-qr-ikev2 has been in RFC Editor queue for 123 days?

On Tue, May 19, 2020 at 10:00:58PM +0300, Valery Smyslov wrote: > Hi, > > > On Tue, 19 May 2020, Benjamin Kaduk wrote: > > > > >> Can the WG chairs or AD see about getting this unstuck and out the > > door? > > > > > > There's a giant backlo

Re: [IPsec] draft-ietf-ipsecme-qr-ikev2 has been in RFC Editor queue for 123 days?

On Tue, May 19, 2020 at 01:36:34PM -0400, Paul Wouters wrote: > > What is going on with draft-ietf-ipsecme-qr-ikev2 ? > > It seems stuck in the RFC Editor queue ? > > Can the WG chairs or AD see about getting this unstuck and out the door? There's a giant backlog in the "RFC-EDITOR" state (see

Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft

On Mon, May 04, 2020 at 09:07:08AM +0300, Valery Smyslov wrote: > Hi Ben, > > > On Wed, Apr 29, 2020 at 10:54:26PM +0300, Yoav Nir wrote: > > > [With chair hat on] > > > > > > Yes, the charter says that we are to make a guidance document. If the > > working group feels that it’s better to put the

Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft

On Wed, Apr 29, 2020 at 10:54:26PM +0300, Yoav Nir wrote: > [With chair hat on] > > Yes, the charter says that we are to make a guidance document. If the working > group feels that it’s better to put the specification and guidance in a > single document, we can work on that and clear it with

Re: [IPsec] revisiting 3DES and -graveyard

Thanks all for the responses; this helps me get a better picture of the state of things and our future direction! On Wed, Apr 15, 2020 at 11:03:49AM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > > I see in > > > https://datatracker.ietf.org/meeting/

[IPsec] revisiting 3DES and -graveyard

Hi all, I see in https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 that we didn't want to get rid of 3DES at that time. Do we have a sense for how quickly that will change, the scope of existing deployments, etc.? In particular, would a general-purpose OS's implementation

Re: [IPsec] terminology check: "modern IPsec protocol suite"

On Thu, Apr 09, 2020 at 09:02:12AM +0300, Valery Smyslov wrote: > Hi, > > > > draft-ietf-taps-transport-security is currently in IESG evaluation, and in > > > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP > > > [RFC4303] together form the modern IPsec protocol suite

[IPsec] terminology check: "modern IPsec protocol suite"

Hi all, draft-ietf-taps-transport-security is currently in IESG evaluation, and in its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either for creating tunnels

Re: [IPsec] Barry Leiba's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

On Tue, Jan 07, 2020 at 09:46:43PM -0800, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: No Objection > [...] > > I also find it interesting that Alexey thought you needed to add a normative > reference for

Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

On Wed, Jan 08, 2020 at 05:41:59PM +0300, Valery Smyslov wrote: > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-ipsecme-qr-ikev2-10: No Objection > > > > -- > > COMMENT: > >

Re: [IPsec] graveyard: deprecate->historic

On Fri, Jan 10, 2020 at 12:01:39AM -0800, Dan Harkins wrote: > > > On 12/23/19 10:46 AM, Benjamin Kaduk wrote: > > Since we're in pedantic process mode... > [snip] > > Perhaps something like "IKEv1 is no longer relevant for Internet > > systems" would

Re: [IPsec] graveyard: deprecate->historic

On Mon, Dec 30, 2019 at 09:41:11PM -0500, Paul Wouters wrote: > On Mon, 23 Dec 2019, Benjamin Kaduk wrote: > > > "this document" (i.e., the RFC-to-be) does not actually effecuate the move > > to Historic status; the separate "status-change" document doe

Re: [IPsec] graveyard: deprecate->historic

Since we're in pedantic process mode... On Tue, Dec 17, 2019 at 02:31:08PM -0500, Sean Turner wrote: > warning: process mumbo jumbo follows > > Technically, I think that s3 of draft-pwouters-ikev1-ipsec-graveyard is > trying to do is move IKEv1 to historic. IKEv1 is already obsoleted by RFC >

Re: [IPsec] Datatracker State Update Notice:

On Thu, Dec 12, 2019 at 10:38:41PM +0200, Tero Kivinen wrote: > Benjamin Kaduk writes: > > It looks like the "reference" column for the registry dind't make it into > > the -09, but I'm happy to include that change along with the last-call > > feedback. > > I

Re: [IPsec] Datatracker State Update Notice:

It looks like the "reference" column for the registry dind't make it into the -09, but I'm happy to include that change along with the last-call feedback. -Ben On Tue, Dec 10, 2019 at 06:00:45PM -0800, IETF Secretariat wrote: > IESG state changed: > > New State: Last Call Requested > > (The

Re: [IPsec] Alternative Approach for Postquantum Preshared Keys in IKEv2

On Wed, Dec 04, 2019 at 11:34:36AM +0300, Valery Smyslov wrote: > > thank you for the thorough review. Seconded! > > Another issue I see is with connection selection and PPK selection. > > At the IKE_INTERMEDIATE exchange, we don't know yet which connection > > this will map to, as we haven't

Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]

On Sun, Dec 01, 2019 at 03:52:30AM -0500, Christian Hopps wrote: > I think it's important for this discussion to recognize that we have 2 > orthogonal issues. > > 1) How does IP-TFS work on the wire with IPsec/ESP - this is where we need to > make sure we don't unnecessarily restrict

[IPsec] IPSECME chair transition

Hi all, Please join me in thanking David Waltermire for his many years of service as IPSECME co-chair; Dave is stepping down to leave more time for his other projects. Thank you, Dave! Taking over from Dave will be Yoav Nir -- welcome Yoav! Thanks to you both, Ben

[IPsec] On internet protocol number assignment requests and draft-hopps-ipsecme-iptfs

Hi all, I know that we are going to try to explore options for draft-hopps-ipsecme-iptfs that do not require a protocol number, but if we do find ourselves pressing forward with that approach, we should be sure to have a discussion about the usage in INTAREA, which in some sense represent the

Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08

Hi Tero, On Fri, Nov 08, 2019 at 03:00:37AM +0200, Tero Kivinen wrote: > Benjamin Kaduk writes: > > Section 3 > > > >N(USE_PPK) is a status notification payload with the type 16435; it > >has a protocol ID of 0, no SPI and no notification data associated >

Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08

On Mon, Nov 04, 2019 at 10:39:46PM -0500, Paul Wouters wrote: > On Mon, 4 Nov 2019, Benjamin Kaduk wrote: > > [ignoring the nits and leaving that to the authors, although reading it > again I would like to see "he" and "she" replaced by "it" everwhere

[IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08

Hi all, Thanks for this document -- it's pretty readable (once I did my background reading on RFC 7296) and is an interim measure that we're seeing some demand for already. Sorry to have been sitting on this for so long; my backlog is taking longer to clear than planned. There are a few

Re: [IPsec] Possible new charter text to cover iptfs.

Hi Chris, On Mon, Oct 21, 2019 at 05:45:27PM -0400, Christian Hopps wrote: > Hi Ben, > > To perhaps speed this up a little bit, could we maybe run the process in > parallel then? We had very positive feedback at the last meeting for adopting > draft-hopps-ipsecme-iptfs-01 draft as a WG item,

Re: [IPsec] Possible new charter text to cover iptfs.

I think we've got a couple potential recharter topics in flight, so I'd like to have the chairs assemble a consolidated version with all the updates in it, so that I can start the formal rechartering process. -Ben On Sun, Oct 13, 2019 at 03:10:36AM -0400, Christian Hopps wrote: > Hi ipsecme and

Re: [IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT)

On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote: >Hi Benjamin, >Thanks you for the comments. Please see in line my responses. >Yours, >Daniel >On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker > wrote: > > Be

[IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-08: 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 paragraph, however.) Please

[IPsec] Benjamin Kaduk's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-07: Discuss 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 paragraph, however.) Please refer

Re: [IPsec] ikev1-graveyard

On Sun, Apr 07, 2019 at 02:11:13PM -0400, Michael Richardson wrote: > > I have read draft-pwouters-ikev1-ipsec-graveyard-00. > > I think that the actual words and organization of the document could use a > bit of polish, but fundamentally it does the right thing, and sends the right > message.

[IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: 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 cut this introductory paragraph, however.) Please refer to https

Re: [IPsec] [Technical Errata Reported] RFC7634 (5441)

On Thu, Jul 26, 2018 at 10:06:30PM +0300, Yoav Nir wrote: > This errata proposes to add the following sentence to section 4 of RFC 7634 > : > > As with other transforms that use a fixed-length key, the Key Length > attribute MUST NOT be specified.

Re: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-11-01: (with COMMENT)

On Fri, Jul 13, 2018 at 05:21:51AM +0300, Tero Kivinen wrote: > > I seem to have missed this email somehow. > > Alissa Cooper writes: > > > (3) > > I can't parse this sentence: > > > > "A growing number of use cases for constrained network - but not > > limited to - have shown interest in

Re: [IPsec] draft-pauly-ipsecme-split-dns

and is also not a WG I'm responsible for, but I'm trying to help brainstorm a way past this apparent impasse. On Wed, Jun 20, 2018 at 03:55:02PM -0400, Paul Wouters wrote: > On Wed, 20 Jun 2018, Benjamin Kaduk wrote: > > > This seems like the main fear, yes, but perhaps not exclusively

Re: [IPsec] draft-pauly-ipsecme-split-dns

On Wed, Jun 20, 2018 at 03:21:52PM -0400, Paul Wouters wrote: > On Wed, 20 Jun 2018, Eric Rescorla wrote: > > > I thought I had made clear what was bothering me, so I suppose we must be > > talking past each other. I read this text as saying that there are > > important cases where in fact the