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

Obligatory: I have read the draft. I strongly support advancing this work to RFC status. We definitely have plans to use this with IP-TFS development both in linux kernel as well as in other projects such as VPP. Thanks, Chris. Tero Kivinen writes: This will start three week working

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

Michael Richardson writes: [[PGP Signed Part:Signature made by expired key 808B70FBDDD0DD65 Michael Richardson ]] Paul Wouters wrote: >> > Or use IPTFS and set your own max packet size sufficiently low? >> >> I think that this is the killer app for IPTFS. >> > But of

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

"Panwei (William)" writes: Hi Daniel, Thanks for your clarification, I think I may have better understanding of your problem statement. I try to give an example below, please correct me if I’m wrong. First, let’s assume the encryption/decryption capability of ingress node is 15000 bytes

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

Hi, FWIW, Here's what I was saying at the mic during the ipsec meeting @117. It may have relevance to the discussion about EMTU... You own the tunnel endpoints since you're configuring security tunnels on them. Normal PMTU will work fine if, for some reason, you need your ingress to discover

Re: [IPsec] IPR disclosure for ESP SPI issue

Do they say what "reasonable and non-discriminatory terms and conditions" are? here's an example of what Cisco has typically used for IETF standards: "The reasonable non-discriminatory terms are: If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco

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

Paul Wouters writes: On Thu, 10 Nov 2022, Pierre Pfister (ppfister) wrote: Since I doubt the working group would have the time and energy to work on two different solutions, my support to this draft's adoption is conditioned to whether the authors plan to consider addressing our concerns

Re: [IPsec] Discussion about solving ESP limitations with parallel processing, handling QoS classes etc.

I'm interested and would attend. Thanks, Chris. Steffen Klassert writes: Hi, over the last years, quite some work was done from different parties to overcome some limitations of ESP to handle parallel datapaths, QoS classes etc. Chronologically ordered, we have: November 2019:

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

: Hi, On 2022-8-25, at 20:29, Christian Hopps wrote: [[RFC3168]] and [[RFC4301]], updated by [[RFC6040]] defines behaviors for marking the outer ECN field value based on the ECN field of the inner packet. As AGGFRAG mode may have multiple inner packets present in a single outer packet

[IPsec] Revised ID posted [Fwd: New Version Notification for draft-ietf-ipsecme-iptfs-19.txt]

, draft-ietf-ipsecme-iptfs-19.txt has been successfully submitted by Christian Hopps and posted to the IETF repository. Name: draft-ietf-ipsecme-iptfs Revision: 19 Title: IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security Document date

Re: [IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)

Hi Zahed, please see inline... Zaheduzzaman Sarker writes: -Original Message- From: iesg On Behalf Of Christian Hopps Sent: den 25 augusti 2022 15:43 To: Zaheduzzaman Sarker Cc: The IESG ; draft-ietf-ipsecme-ip...@ietf.org; ipsecme-cha...@ietf.org; ipsec@ietf.org; kivi...@iki.fi

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

As we were directed by both INT ADs at this point, and had no object by the other ADs during the telechat call, I've treated this as a "take our money" moment and have requested early allocation of an IP protocol code point to move things forward. If in the (distant?) future INT needs to take

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

text above satisfies this requirement I beleive. Agreed? - Zaheduzzaman - You added a +1 to Lars' DISCUSS for ECN. Would you also be satisfied with the above text? Thanks, Chris. Martin On Wed, Aug 24, 2022 at 5:46 AM Christian Hopps wrote: Christian Hopps writes: >> On

Re: [IPsec] John Scudder's No Objection on draft-ietf-ipsecme-iptfs-17: (with COMMENT)

John Scudder via Datatracker writes: -- COMMENT: -- Nit: I just happened to notice this bit in the Intro: "While directly obscuring the data with

Re: [IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)

Hi Zaheduzzaman, [inline] Zaheduzzaman Sarker via Datatracker writes: Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ipsecme-iptfs-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Lars Eggert writes: Sorry for the top post. The text below is not sufficient. 8084 gives guidance on how to specify a CB , but doesn’t itself specify a solution that can just be pointed to. This document needs to define how, based on the guidance in 8084, a CB should be implemented for

Re: [IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)

Murray Kucherawy via Datatracker writes: -- DISCUSS: -- Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a registry, Section 4.5

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Christian Hopps writes: [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps (trust ultimate) created at 2022-08-25T02:18:48-0400 using RSA]] "Eric Vyncke (evyncke)" writes: Chris, The -17 version indeed addresses one of the 4 DISCUSS points, namely the hop

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

e already occurred prior to you being handed your AGGFRAG payload to act on. Thanks, Chris. The DISCUSS on the next header still holds of course. As I suggested, either update RFC 4303/8200 or request an IP protocol number. Regards -éric On 24/08/2022, 18:49, "iesg on behalf of Christia

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

> On Aug 25, 2022, at 01:17, Christian Hopps wrote: > > > >> On Aug 25, 2022, at 00:52, Erik Kline wrote: >> >> >> >>> I.e., either this document needs to formally update RFC 4303 by allowing any >>> number or another IP protocol num

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

> On Aug 25, 2022, at 00:52, Erik Kline wrote: > > > > > I.e., either this document needs to formally update RFC 4303 by allowing any > > number or another IP protocol number must be requested to the IANA. > > As I pointed out in my previous email that is not the case. > > The RFC4303

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Warren Kumari writes: On Wed, Aug 24 2022 at 8:35 PM, Christian Hopps wrote: If you own/control/have the rights to the entire network, then you have the same over all the paths through the network. There are organizations that wish to deploy IPTFS protected tunnels

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Hi Warren, Warren Kumari writes: On Wed, Aug 24, 2022 at 5:33 AM, Lars Eggert wrote: This CBR ESP tunnel is basically identical to a CBR pseudowire. There was quite a bit of work/discussion between PWE3 and various transport groups in the past that resulted in a set of guidance

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Warren Kumari writes: On Wed, Aug 24, 2022 at 5:33 AM, Lars Eggert wrote: Hi, On 2022-8-24, at 2:08, Christian Hopps wrote: How about we add the text "This MUST NOT be used when full admin control over the network cannot be assured."? I don't really

[IPsec] Fwd: New Version Notification for draft-ietf-ipsecme-iptfs-17.txt

This version has changes requested in the remaining DISCUSS ballot items from Lars (Warren's +1), and Eric. Thanks, Chris. internet-dra...@ietf.org writes: A new version of I-D, draft-ietf-ipsecme-iptfs-17.txt has been successfully submitted by Christian Hopps and posted to the IETF

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Éric Vyncke via Datatracker writes: -- DISCUSS: -- ## DISCUSS ### Section 2.2.6 Please also mention hop-limit and RFC 8200. ### Absence of ICMP

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Christian Hopps writes: On Aug 24, 2022, at 04:28, Lars Eggert wrote: ### Section 3.1, paragraph 0 ``` 3.1. ECN Support ``` There is a lot more nuance to this, as described in RC6040. This document needs to follow that existing standard rather than define another variant. We reference

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

> On Aug 24, 2022, at 04:28, Lars Eggert wrote: > >> We deal with that by indicating the RTT is *at least* 4 seconds. Remember >> that we are implementing a fixed-rate tunnel here. If the RTT is at least 4 >> seconds it's going to basically slow the tunnel to a standstill and so is >> way

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

> On Aug 24, 2022, at 04:28, Lars Eggert wrote: > >>> ### Section 3.1, paragraph 0 >>> ``` >>> 3.1. ECN Support >>> ``` >>> There is a lot more nuance to this, as described in RC6040. This document >>> needs >>> to follow that existing standard rather than define another variant. >> >> We

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Hi Lars, > On Aug 24, 2022, at 04:28, Lars Eggert wrote: > >> >> This text is talking to implementations not users. It's suggesting >> implementations *also* offer circuit breaker functionality. >> >>> What would make sense is to use circuit breakers in the >>> non-congestion-controlled

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

> On Aug 24, 2022, at 05:33, Lars Eggert wrote: > > Hi, > > On 2022-8-24, at 2:08, Christian Hopps wrote: >> How about we add the text "This MUST NOT be used when full admin control >> over the network cannot be assured."? > > "full admin

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Hi Lars, Lars Eggert writes: On 2022-8-23, at 18:57, Christian Hopps wrote: ### Section 2.4.2, paragraph 0 ``` 2.4.2. Congestion-Controlled Mode ``` This mode adds a LOT of complexity to this mechanism. Is this really needed? Could not RFC8229 be used instead of defining an entirely

Re: [IPsec] IP-TFS telechat prep Implementation Status section added

It has been suggested that adding an implementation status section to the draft would help with IESG evaluation. Thus, version 15 of the document has been published with an added "Implementation Status" section discussing 2 known implementations (one full and complete, one in progress) An

[IPsec] IP-TFS telechat prep Implementation Status section added

n progress) Thanks, Chris. A new version of I-D, draft-ietf-ipsecme-iptfs-15.txt has been successfully submitted by Christian Hopps and posted to the IETF repository. Name: draft-ietf-ipsecme-iptfs Revision: 15 Title: IP-TFS: Aggregation and Fragmentation Mode for ESP and its U

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Warren Kumari via Datatracker writes: Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: Discuss -- DISCUSS: -- How

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Replying to COMMENT here.. Given a few of the comments I think it's useful to point this out at the top. This document defines a constant send rate tunnel of OUTER packets, the actual data encapsulated is not constant rate and so can and will be encapsulated along with padding in the outer

Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

Lars Eggert via Datatracker writes: Lars Eggert has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: 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

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)

tunnelling protocol, which is usually INTAREA topic, and I cannot refrain from thinking that this tunnelling mechanism could be used on any connection-less transport, e.g., UDP or IP. Hence, this DISCUSS point is only to initiate a discussion with IPSECME chairs and AD; Christian Hopps has already

Re: [IPsec] [Int-area] Can you review draft-ietf-ipsecme-iptfs as it is about tunnels ?

n for many years now, for which there are waiting users. Thanks, Chris. NB: else, I find this document quite useful. Regards -éric [1] hoping that not everyone is on vacation mode as it is August... On 10/08/2022, 20:03, "Int-area on behalf of Christian Hopps" wrote: I'

Re: [IPsec] Martin Duke's Discuss on draft-ietf-ipsecme-iptfs-13: (with DISCUSS and COMMENT)

PM Christian Hopps wrote: Martin Duke writes: > Comments inline. > > On Tue, Aug 9, 2022 at 8:56 PM Christian Hopps < cho...@chopps.org> > wrote: > > >     Thanks for the thorough review! Comments inline.. > >     Ma

Re: [IPsec] Martin Duke's Discuss on draft-ietf-ipsecme-iptfs-13: (with DISCUSS and COMMENT)

Martin Duke writes: Comments inline. On Tue, Aug 9, 2022 at 8:56 PM Christian Hopps wrote: Thanks for the thorough review! Comments inline.. Martin Duke via Datatracker writes: > (6) As malformed packets are sometimes an attack vector, it would be good to > s

Re: [IPsec] Can you review draft-ietf-ipsecme-iptfs as it is about tunnels

I'll paraphrase what I replied to on the ballot proposal deferment thread: We designed the encapsulation with IPsec/IP-TFS (IP traffic flow security) in mind. This work defines sending fixed-sized packets at a constant rate specifically decoupled from the user load to achieve a high degree of

Re: [IPsec] Martin Duke's Discuss on draft-ietf-ipsecme-iptfs-13: (with DISCUSS and COMMENT)

Thanks for the thorough review! Comments inline.. Martin Duke via Datatracker writes: Martin Duke has entered the following ballot position for draft-ietf-ipsecme-iptfs-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-iptfs-12

Hi Peter, Thanks very much for your thorough review! I've placed comments/actions taken inline below. And one question at the very end. :) Peter Yee via Datatracker writes: Reviewer: Peter Yee Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General

Re: [IPsec] ESP Signally to higher layers

Robert Moskowitz writes: This is an item that goes back to the beginning of ESP work: Minimally, how does the higher level 'learn' that it is secure: E2E or TE2TE? Encrypted/Authenticated/CrCed...  ? And as ESP has a seq#, how might it be convied to the higher layer? Case in point: 

Re: [IPsec] Opsdir last call review of draft-ietf-ipsecme-iptfs-12

Hi Bo, Thanks for your review! I've addressed your comments below along with local modifications to the document as noted. Bo Wu via Datatracker writes: Reviewer: Bo Wu Review result: Has Nits Hi all, I have been selected as the Operational Directorate reviewer for this draft. Summary: I

Re: [IPsec] AD Review of draft-ietf-ipsecme-iptfs-12

Hi Roman, Thanks for the review! I've made some changes in the document to cover most of your suggestions and have a few comments/questions on the rest below. Roman Danyliw writes: Hi! I performed an AD review of draft-ietf-ipsecme-iptfs-12. Thank you for this work and the patience of

Re: [IPsec] IP-TFS YANG and MIB Updated

Tero Kivinen writes: Don Fedyk writes: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-03.txt While answering the shepherd writeup question "Briefly describe the review of this document that was perfmed by the Document Shepherd", I had to read this document too, so here are

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

I believe this is a good time to apply KISS method. We have a lost packet timer and additionally this is the "in order delivery" mode. Let's not make this more complex to try and eek out every ounce of potential, especially given we are already documenting 2 possible receiver behaviors

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

Paul Wouters writes: On Mon, 8 Nov 2021, internet-dra...@ietf.org wrote: Filename: draft-ietf-ipsecme-iptfs-12.txt A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-12 Looks good to me other than a typo: s/the

Re: [IPsec] IPsecME WG agenda requests for IETF 112

Since we continue to have an unresolved issue on the iptfs draft, I think it's best if we have a 10m slot to close it, and get the document shipped. Thanks, Chris. > On Oct 31, 2021, at 2:39 PM, Tero Kivinen wrote: > > We will be meeting on Monday November 8th 12:00-14:00 UTC, so send me >

Re: [IPsec] iptfs publication request

oth being a MAY and a recommendation for this to be > configurable. > > Lou > > On 10/31/2021 3:53 PM, Michael Richardson wrote: >> Tero Kivinen wrote: >> > Christian Hopps writes: >> >> Will you be able to provide the text changes that would cov

Re: [IPsec] iptfs publication request

Hi Tero, Will you be able to provide the text changes that would cover the issue you have? Would really like to get this submitted to IESG before another IETF cycle completes. Thanks, Chris. Christian Hopps writes: It was resolved with the transport area by adding the drop timer. I added

Re: [IPsec] iptfs publication request

is spread over multiple paths. > > Cheers, > > Paul > > > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Graham Bartlett > Sent: Monday, September 6, 2021 1:18 PM > To: Christian Hopps > Cc: Koning, Paul ; ipsec@ietf.org; > to...@strayalpha.com; Tero

Re: [IPsec] iptfs publication request

> On Sep 7, 2021, at 3:13 AM, Paul Wouters wrote: > > > On Mon, Sep 6, 2021 at 11:27 PM Christian Hopps <mailto:cho...@chopps.org>> wrote: >> On Sep 6, 2021, at 4:16 PM, Tero Kivinen > <mailto:kivi...@iki.fi>> wrote: >> >> Christian Hopp

Re: [IPsec] iptfs publication request

> On Sep 6, 2021, at 4:16 PM, Tero Kivinen wrote: > > Christian Hopps writes: >> At this point please suggest the text that you would like changed or >> added to this document. I object to having to add it, but you are >> the chair and you are blocking this documen

Re: [IPsec] iptfs publication request

Tero Kivinen writes: Christian Hopps writes: Christian Hopps writes: > > I'm saying we should add new text that mentions the use of this > drop timer to drop missing packets after a short waiting time > instead of just waiting for it to slide out of the re

Re: [IPsec] iptfs publication request

Christian Hopps writes: I'm saying we should add new text that mentions the use of this drop timer to drop missing packets after a short waiting time instead of just waiting for it to slide out of the reorder window. Then there is no issue to discuss anymore AFAICT. A new version has been

Re: [IPsec] iptfs publication request

Tero Kivinen writes: Christian Hopps writes: I also need to point out that we are only talking about the case where the implementation doesn’t use a timer to timeout missing packets. We specifically added text highlighting that implementations are free to timeout missing packets much earlier

Re: [IPsec] iptfs publication request

highlight this again?? Thanks, Chris. > On Aug 17, 2021, at 9:22 AM, Christian Hopps wrote: > > In particular why don’t we simply indicate that a lost packet can induce a > delay of the fixed packet interval times the window size - 1, and so the > widow size should be kept to a min

Re: [IPsec] iptfs publication request

In particular why don’t we simply indicate that a lost packet can induce a delay of the fixed packet interval times the window size - 1, and so the widow size should be kept to a minimum, and leave it at that. Thanks, Chris. > On Aug 17, 2021, at 9:15 AM, Christian Hopps wrote: > >

Re: [IPsec] iptfs publication request

with the approved text and make clarifying modifications only. Thanks, Chris. > On Aug 17, 2021, at 6:48 AM, Tero Kivinen wrote: > > Christian Hopps writes: >>>> It might be obvious to you, but it might not be obvious to the person >>>> doing the actual implementations.

Re: [IPsec] iptfs publication request

> On Aug 16, 2021, at 5:22 PM, Koning, Paul wrote: > > > >> On Aug 16, 2021, at 5:09 PM, Tero Kivinen wrote: >> >> ... >>> Adding a more text pointing out the obvious results of this choice >>> (i.e., that sending inner packets early can create downstream out of >>> order delivery, or that

Re: [IPsec] iptfs publication request

> On Aug 16, 2021, at 1:45 PM, Tero Kivinen wrote: > > Christian Hopps writes: >> During the last IETF meeting it was agreed that we would move >> quickly to resolve any issues that Tero had left, and get this >> document submitted to the IESG. So asking again if th

Re: [IPsec] iptfs publication request

. > On Jul 5, 2021, at 3:48 AM, Christian Hopps wrote: > > > Christian Hopps writes: > >> Hi Tero, >> >> I understand you have some additional post-WGLC technical comments on the >> draft. I'm sending this message to start a discussion thread so that the &

Re: [IPsec] iptfs publication request

Christian Hopps writes: Hi Tero, I understand you have some additional post-WGLC technical comments on the draft. I'm sending this message to start a discussion thread so that the issue can be resolved and we can move forward on the publication request. I have published a new version

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

Michael Richardson writes: [[PGP Signed Part:Signature made by expired key 808B70FBDDD0DD65 Michael Richardson ]] I think you'll all be happier with a virtual interim meeting with no conflicts. We can now use meetecho even. It has been my (admittedly limited) experience that the IETF

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

Benjamin Kaduk writes: 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,

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

> 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 hope that is a mistake that can be fixed I suspect it still can, but ti

[IPsec] ipsecme not meeting @ IETF 111?

I don’t see ipsecme scheduled at IETF 111, is there no meeting? Thanks, Chris. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] iptfs publication request

Hi Tero, I understand you have some additional post-WGLC technical comments on the draft. I'm sending this message to start a discussion thread so that the issue can be resolved and we can move forward on the publication request. Thanks, Chris.

Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs

The replay window does not need to be the same size as the reorder window. Thanks, Chris. > On Apr 30, 2021, at 11:58 AM, Tero Kivinen wrote: > > Christian Hopps writes: >> >> For very slow tunnels such as your indicating, you are not worried >> about out-

Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs

For very slow tunnels such as your indicating, you are not worried about out-of-order delivery; just set the reorder window to 0. FWIW, the interest we are aware of is for 1GE to 100GE general purpose tunnels. Thanks, Chris. Tero Kivinen writes: Christian Hopps writes: I'm not sure what

Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs

I'm not sure what you mean by Huge delays. Given an example of a 10 kilobit tunnel (really?) means *everything* is super slow, so then reporting raw wall clock times is a bit disingenuous I think. I didn't actually look over the math b/c this just doesn't seem realistic. Have you considered

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

ork item of the IP Security Maintenance and Extensions WG of > the IETF. > >Title : IP-TFS: Aggregation and Fragmentation Mode for ESP > and its Use for IP Traffic Flow Security > Author : Christian Hopps > Filename: draft-iet

Re: [IPsec] Proposed changes to draft-ietf-ipsecme-iptfs-07

If there are no objections from the WG I will incorporate these changes with some edits (e.g., we refer to congestion control and non-congestion control as modes already so I'll need to change the way those are referred to, to avoid confusion with the new term "AGGFRAG mode"). Thanks, Chris.

[IPsec] WGLC Summary [Re: WGLC for draft-ietf-ipsecme-iptfs]

Here's a summary of the changes based on WGLC WG mailing list discussions and reviews (published in the latest -07 document). There were 2 minor normative clarifications/changes, clarified the intent that fragmentation should not occur over different SAs, and added a P-bit that is for external

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

> On Feb 27, 2021, at 3:14 PM, Michael Richardson wrote: > > Signed PGP part > > Christian Hopps wrote: >>> I still don't really see enough explanation of: >>> >>> 1) what do my probe packets look like? Can I, for instance, send >>>

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

> On Feb 26, 2021, at 12:21 PM, Michael Richardson > wrote: > > > Christian Hopps wrote: >>> Christian Hopps wrote: >>>>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do >>>>> use PLMTUD? Will you tell us later in th

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

> On Feb 16, 2021, at 6:11 AM, Christian Hopps wrote: > > Hi Michael, > > Thanks for the review, q's, comments, and changes inline.. > >> On Feb 14, 2021, at 11:45 PM, Michael Richardson > <mailto:mcr+i...@sandelman.ca>> wrote: >> >> Signe

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

> On Feb 16, 2021, at 12:47 PM, Michael Richardson > wrote: > > Signed PGP part > > Christian Hopps wrote: >>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do use >>> PLMTUD? Will you tell us later in the document, or is that new work?

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

Hi Michael, Thanks for the review, q's, comments, and changes inline.. > On Feb 14, 2021, at 11:45 PM, Michael Richardson > wrote: > > Signed PGP part > > I have read draft-ietf-ipsecme-iptfs before it was adopted, and during the > adoption call, but have been busy. So I have read it again

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

Hi Tero, Just to clarify, are you indicating Valery's changes should be made? If so then I will update the document so we can continue to make progress. Thanks, Chris. > On Feb 11, 2021, at 5:52 PM, Christian Hopps wrote: > > Signed PGP part > Hi Tero, > > I'm sorry so

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

, Chris. > On Feb 11, 2021, at 2:16 PM, Tero Kivinen wrote: > > Christian Hopps writes: > properly as it was in HTML format and my client could not parse that > html out for quoting> > > WGLC is not too late to do changes, it is quite early in the process, > we stil

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

Hi Valery, I think we're getting a bit too caught in the details, to circle back: > I think that in its current form the draft is too focused on a single > application for > the Aggregation and Fragmentation mode - IP-TFS. From architectural > point of view I'd like to see the draft first

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

As there have been a number of editorial changes (nits etc), to help any remaining reviewers here's a pointer to the current text which includes the changes made so far during the WGLC:

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

> On Feb 10, 2021, at 3:36 AM, Valery Smyslov wrote: > > Hi Christian, > >>> On Feb 8, 2021, at 6:44 AM, Valery Smyslov wrote: >>> >>> Hi, >>> >>> I think that in its current form the draft is too focused on a single >>> application for >>> the Aggregation and Fragmentation mode - IP-TFS.

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

> On Feb 8, 2021, at 6:44 AM, Valery Smyslov wrote: > > Hi, > > I think that in its current form the draft is too focused on a single > application for > the Aggregation and Fragmentation mode - IP-TFS. From architectural > point of view I'd like to see the draft first defining the mechanism

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

> On Feb 3, 2021, at 10:38 PM, Sean Turner wrote: > > Hi! I mostly just have nits, but there are a couple of questions interspersed > below. Hi Sean, Thanks so much for this very thorough review! I have made the vast majority of the suggested changes with only a few style exceptions (and

Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs

Support as co-author, and I'm not aware of any IPR for this document. Thanks, Chris. > On Jan 24, 2021, at 8:59 PM, Tero Kivinen wrote: > > This is the start of 3 week WG adoption call for this document, ending > 2021-02-15. Please send your reply about whether you support adopting > this

Re: [IPsec] My review of the draft-ietf-ipsecme-iprfs-05.txt

> On Jan 24, 2021, at 8:53 PM, Tero Kivinen wrote: > > Christian Hopps writes: >> I have published a new version of the draft which I believe >> addresses the issues you raise in your WGLC readiness review below. >> As such, I'd like to request the document

Re: [IPsec] My review of the draft-ietf-ipsecme-iprfs-05.txt

Hi Tero, I have published a new version of the draft which I believe addresses the issues you raise in your WGLC readiness review below. As such, I'd like to request the document enter WGLC. Changes indicated inline below. > On Jan 17, 2021, at 4:27 PM, Tero Kivinen wrote: > > First, thanks

Re: [IPsec] IP-TFS drafts calls.

> On Jan 17, 2021, at 4:34 PM, Tero Kivinen wrote: > > Christian Hopps writes: >> Also, as per the last IETF meeting, can we please start an WG >> adoption call on the supporting YANG draft? >> >> https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-ya

[IPsec] IP-TFS drafts calls.

Hi, Now that the IP-TFS draft has also completed its transport area review, can we start a WGLC on it? https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ Also, as per the last IETF meeting, can we please start an WG adoption call on the supporting YANG draft?

Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03

Hi Joe, Could you also clear the not-ready mark in the datatracker? Thanks, Chris. > On Dec 23, 2020, at 5:33 PM, Joseph Touch wrote: > > Looks good - thanks. > > Joe > >> On Dec 19, 2020, at 8:44 PM, Christian Hopps > <mailto:cho...@chopps.org>> wrote: &

Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03

hanges: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-05 <https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-05> Thanks, Chris. > On Dec 19, 2020, at 7:57 PM, Joseph Touch wrote: > > > >> On Dec 19, 2020, at 2:16 PM, Christian Hopps >

Re: [IPsec] Tsvart early review of draft-ietf-ipsecme-iptfs-03

> On Dec 4, 2020, at 3:14 AM, Christian Hopps wrote: Looking through this list I realized one thing. We are not technically defining a new tunnel here. We are defining a new payload for the already defined IPsec/ESP tunnel. So many of these points are covered by the base ESP tunnel docum

Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03

Changes are underway. One comments inline. > On Dec 4, 2020, at 11:42 AM, Joseph Touch wrote: > > Hi, Christian, [...] >>> There is no clear utility in having the blockoffset point past the end of >>> the >>> current packet. It serves – at best – as only a partially useful check on >>> the

Re: [IPsec] Some cosmetic cleanup to IPTFS draft.

t; >> Sent from my iPhone >> >>> On Nov 25, 2020, at 08:35, Christian Hopps wrote: >>> >>> AGGFRAG >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinf

Re: [IPsec] YANG for IP-TFS

Is there anything holding this up? Thanks, Chris. > On Dec 3, 2020, at 11:37 AM, Don Fedyk wrote: > > Hi > > As asked in the 109 meeting, could we start the call for adoption for > draft-fedyk-ipsecme-yang-iptfs-01 > ? > >

Re: [IPsec] Tsvart early review of draft-ietf-ipsecme-iptfs-03

Hi Joseph, First, thanks for your review. This is an initial reply to clarify a couple points [inline]. > On Dec 4, 2020, at 1:26 AM, Joseph Touch via Datatracker > wrote: > > Reviewer: Joseph Touch > Review result: Not Ready > > This documents most significant transport issue is the use of

  1   2   >