Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt

Michael Richardson writes: Valery Smyslov wrote: > And I really want to make reassembling feature optional and negotiable. It seems to me that the receiver has to indicate that it supports it or not, (just like we do for compression), and the sender either uses it or does not. This seems

Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt

s well. Thanks, Chris. internet-dra...@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Traffic Flow Security > Author : Christian Hopps >

Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt

Paul Wouters writes: Just to clarify. It is not that people are not open minded, but that the suggested change technically cannot work due to the base model of how IKEv2 works. The way msgid handling is specified in the core spec cannot support uni-directional behaviour even if we all

Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt

Valery Smyslov writes: If there really is no way to work around this, I suppose we just require retransmissions of CC info reports until they are ACKd or things are torn down b/c of drops (i.e., normal INFO exchange). It does feel like we are adding fragility here that isn’t really needed

Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt

Sure, I'm definitely open to changes, and in particular with the congestion info report. This is just the first draft. :) So my reading of IKEv2 indicated that one way notifications were supported, not that they were *only* to be used for unprotected error notification though. Yes, they are

Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt

> On Mar 12, 2019, at 10:34, Valery Smyslov wrote: > > Hi Chris, > >> Sure, I'm definitely open to changes, and in particular with the congestion >> info report. This is just the first >> draft. :) >> >> So my reading of IKEv2 indicated that one way notifications were supported, >> not

Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt

> On Mar 12, 2019, at 10:39, Valery Smyslov wrote: > > Hi Chris, > >> There are other ways to skin this cat though. :) >> >> One option is that instead of sending a new CC info report on the interval >> timer expiry if we haven't received a >> response "ack" yet, we simply update the data

[IPsec] Update to IP-TFS [Fwd: I-D Action: draft-hopps-ipsecme-iptfs-01.txt]

directories. > > >Title : IP Traffic Flow Security >Author : Christian Hopps > Filename: draft-hopps-ipsecme-iptfs-01.txt > Pages : 25 > Date: 2019-06-05 > > Abstract: > This document describes a

[IPsec] Possible new charter text to cover iptfs.

Hi ipsecme and chairs, As discussed @IETF105 we need to update the charter in order to adopt the IPTFS draft, how does this look for addition to the charter? " The demand for Traffic Flow Confidentiality has been increasing in the user community; however, the current method defined in RFC4303

Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

Hi, So did the adoption poll succeed? :) Thanks, Chris. > On Oct 26, 2019, at 11:17 AM, Tero Kivinen wrote: > > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did have quite positive feedback in last IETF meeting and

Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01

> On Dec 3, 2019, at 6:02 AM, Valery Smyslov wrote: > >>> Adding a packet ID also means that you can't just chain the inner traffic >>> buffers together to form the IP-TFS >> payload as you must now insert an extra header between each of the inner >> packets, this is going to affect >>

Re: [IPsec] IPSECME chair transition

Thanks David! Welcome Yoav! Thanks, Chris. > On Nov 25, 2019, at 7:54 PM, Benjamin Kaduk wrote: > > 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,

Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

As author, I know of no IPR that applies to this draft, and support its adoption by the WG. Thanks, Chris. > On Oct 26, 2019, at 11:17 AM, Tero Kivinen wrote: > > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did

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

cess. > > -Ben > > On Sun, Oct 13, 2019 at 03:10:36AM -0400, Christian Hopps wrote: >> Hi ipsecme and charis, >> >> It seems like we've had a good amount of soak time on this. :) >> >> What are the next steps? >> >> Thanks, >> Chris. &g

[IPsec] Request for call for adoption contingent on charter changes.

-ipsecme-iptfs-01. It would be great to make some progress on this prior to the next meeting which is imminent. :) Thanks, Chris. Benjamin Kaduk writes: 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

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

> On Nov 29, 2019, at 2:23 PM, Michael Richardson wrote: > > > Christian Hopps wrote: >> Additionally, I'm not sure that we should be so quick to say that the >> IP-TFS payload would never be used outside of ESP; as was pointed out >> by Michael using this pay

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

> On Nov 29, 2019, at 11:14 AM, Valery Smyslov wrote: > >>> I envision a lively discussion with INT folks if we ask them for a "fake" >>> protocol number :-) >> >> I would not choose to refer to it as a fake protocol. The field is defined >> as an IPv4 or IPv6 protocol value to >> identify

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

ote: > > On Fri, 29 Nov 2019, Christian Hopps wrote: > >>> ESP SAs are always created in pairs. And whether IP-TFS is enabled or not >>> is common for both SAs. >>> Even if you use only one SA for IP-TFS traffic, the other will have IP-TFS >>> enabled too

Re: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]

> On Nov 30, 2019, at 1:35 AM, Paul Wouters wrote: > > > On Nov 29, 2019, at 21:01, Valery Smyslov wrote: > >> A lot of things in IKEv2 is negotiated by using notifications. With regard >> to child SA they are - >> using transport mode, using IPcomp, using WESP, using ROHC. >> IP-TFC

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

> On Dec 1, 2019, at 9:28 PM, Benjamin Kaduk wrote: > > 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 wi

Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01

> On Dec 2, 2019, at 3:01 AM, Steffen Klassert > wrote: > > On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote: >> Hi, >> >> after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts. >> >> 1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS

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

> On Nov 28, 2019, at 8:49 AM, Valery Smyslov wrote: > > 2. I don't think new IP protocol number is needed at all. Since SA is created > with IKEv2, > it is always known whether it is IPTFS SA or ordinary SA, so "Next > Protocol" > field in ESP trailer is redundant and can be filled

Re: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]

> On Nov 29, 2019, at 7:09 AM, Valery Smyslov wrote: > > Hi Chris, > >> Transforms aren't just about the encryption algorithm though (e.g., the >> extended sequence number >> transform). > > Whether you want to use ESN or not can depend on selected cryptographic > algorithms > (there is

[IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]

Transforms aren't just about the encryption algorithm though (e.g., the extended sequence number transform). In the IP-TFS case it's not about whether one would enable TFS with a given encryption algorithm. Consider supporting and/or selecting from the set of IP-TFS with congestion control,

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

Hi ipsecme and charis, It seems like we've had a good amount of soak time on this. :) What are the next steps? Thanks, Chris. > On Aug 7, 2019, at 7:04 PM, Paul Wouters wrote: > > Seems broad enough - works for me > > Sent from mobile device > >> On Aug 7, 2019, a

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

and Extensions WG of > the IETF. > >Title : IP Traffic Flow Security > Author : Christian Hopps > Filename: draft-ietf-ipsecme-iptfs-01.txt > Pages : 25 > Date: 2020-03-02 > > Abst

[IPsec] IPTFS_PROTOCOL IP protocol number.

During the last IETF (106) a discussion ensued on the allocation of the IP protocol number for IPTFS payloads. I've looked at the options presented: 1) Use WESP (wrapped ESP) 2) Use protocol number zero, and depend on configuration. 3) Just allocate a number this is a valid use. I think

Re: [IPsec] IPTFS and transport mode.

> On May 3, 2020, at 1:08 PM, Michael Richardson wrote: > > > Christian Hopps wrote: >> non-TFS tunnel mode as the IP header was leaking user information so it >> hadn't been a consideration for us; however, it was later pointed out >> (by Paul W. I

Re: [IPsec] Holding a virtual interim meeting. Or not

I think it would be useful to have a virtual interim to go over the changes made and yet to be made in the IPTFS work. We have an open issue on transport mode support that might benefit from a live discussion. Thanks, Chris. > On Mar 20, 2020, at 5:03 PM, Yoav Nir wrote: > > Hi all. > > As

[IPsec] IPTFS and transport mode.

Hi ipsecme, An open issue we have for IPTFS is the use of transport mode. During the last face-to-face IETF meeting transport mode was mentioned, and my response had been that transport mode was less secure than non-TFS tunnel mode as the IP header was leaking user information so it hadn't

[IPsec] Next IPTFS doc update question

Hi Folks, I'll be posting a new version of https://www.ietf.org/archive/id/draft-ietf-ipsecme-iptfs-01.txt in the next couple days, and have one edit to ask about. Early in the document development process there was a request by Valery (perhaps supported by Paul W?) to remove the

Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

; Hope this helps. >>>>> >>>>> Best Regards. >>>>> >>>>>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) >>>>>> >>>>> <mailto:rwilton=40cisco@dmarc.ietf.org>> escribió: >>

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Indeed, this isn't about switching a pair of SAs to IPTFS in the middle of the tunnel operation. This is only about supporting the receipt of IPTFS as a payload in ESP. Zero conf (or globally config enabled) receive support of IPTFS payloads is seen by some as a real value add. I'm not sure

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

What is intended is that an implementation can process inbound IPTFS payloads w/o actually explicitly configuring the inbound SA to be in "IPTFS-mode" (zero-conf). That is all. Thanks, Chris. > On Oct 14, 2020, at 4:01 AM, Valery Smyslov wrote: > > HI Chris, > >> Indeed, this isn't about

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

. Thanks, Chris. > On Oct 15, 2020, at 4:06 PM, Tero Kivinen wrote: > > Christian Hopps writes: >> I really don't understand the extreme back pressure against using >> ESP the way it was designed. The next-header field is supposed to >> identify the payload, it does so

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

. Thanks, Chris. > On Oct 15, 2020, at 4:06 PM, Paul Wouters wrote: > > On Wed, 14 Oct 2020, Christian Hopps wrote: > >> I really don't understand the extreme back pressure against using ESP the >> way it was designed. The next-header field is supposed to identify the

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

> On Oct 15, 2020, at 4:48 PM, Tero Kivinen wrote: > > Christian Hopps writes: >> We are defining the payload in this document, the payload is meant >> for ESP. ESP has a payload identifier why can't we use it? > > If that is only possible value the next-header fiel

[IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

WG of > the IETF. > >Title : IP Traffic Flow Security > Author : Christian Hopps > Filename: draft-ietf-ipsecme-iptfs-02.txt > Pages : 26 > Date: 2020-09-30 > > Abstract: > This documen

Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

ise. >> >> Thanks, >> Rob >> >> >> From: yang-doctors > <mailto:yang-doctors-boun...@ietf.org>> On Behalf Of Lou Berger >> Sent: 27 September 2020 15:26 >> To: Christian Hopps mailto:cho...@chopps.org>>; Martin >> Björklun

Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

> On Oct 13, 2020, at 12:15 AM, Rafa Marin-Lopez wrote: > > Hi Christian (, Rob): > > Thanks for your comments. We really appreciate them. Please see some comments > inline. > >> El 12 oct 2020, a las 22:21, Christian Hopps > <mailto:cho...@chopps.org>&

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

ful clarification, thanks. >> >> Regards, >> Valery. >> >>> We feel the document is quite stable at this point and would thus like to >>> ask for moving to WG Last Call. >>> >>> Thanks, >>> Chris. >>> >>>>

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

> On Oct 14, 2020, at 6:19 AM, Tero Kivinen wrote: > > Christian Hopps writes: >> What is intended is that an implementation can process inbound IPTFS >> payloads w/o actually explicitly configuring the inbound SA to be in >> "IPTFS-mode" (zero-conf). That

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

I really don't understand the extreme back pressure against using ESP the way it was designed. The next-header field is supposed to identify the payload, it does so for every other payload ESP carries. Any other solution to somehow infer the payload type some other way *has* to be seen as a

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

t; >> Lou >> >>> So, please, remove it. >>> >>>> 2. It highlights that one must send payloads that carry inner packet >>>> fragments using consecutive ESP >>>> sequence numbered packets (with a caveat for all pad payload insertion).

Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[adding in ipsec@] Hi, This draft was discussed in ipsecme at the last IETF, and there was a desire to look closer at a couple changes that would make these models usable by ipsec generally rather than only for SDNs. Otherwise we will end up with 2 models that look very similar and duplicate

Re: [IPsec] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez wrote: > >> >> >> But I would like to check: My understanding is that the changes that Chris >> is proposing are pretty small. I.e. move the SA structure under >> ipsec-common, and put it under a YANG feature. Are you sure that it is >>

Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

> On Sep 23, 2020, at 6:58 AM, Martin Björklund wrote: > > Hi, > > Christian Hopps mailto:cho...@chopps.org>> wrote: >> >> >>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez wrote: >>> >>>> >>>> >>&

Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

that the modules should have "-sdn-" in >> their names to indicate that they are intended specifically for the >> SDN use case, and should not be confused with the more generic ipsec >> YANG modules that have been proposed. >> >> Regards, >> Rob >

[IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number.

Dear ipsecme Chairs, This request is inline with the guidelines as set forth in RFC7120 (https://tools.ietf.org/html/rfc7120) I would like to request early allocation of the IP protocol number [A] used for the ESP payload identifier for IPTFS (suggested value is 144 or next available) as

Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number.

> On Jun 2, 2020, at 10:21 AM, Tero Kivinen wrote: > > Christian Hopps writes: >> Dear ipsecme Chairs, >> >> This request is inline with the guidelines as set forth in RFC7120 >> (https://tools.ietf.org/html/rfc7120) >> >> I would like to reque

[IPsec] Early Allocation Request for IPTFS protocol number

Hi, Based on the list discussion I put together a draft early allocation request (using the form https://www.iana.org/form/protocol-assignment) I think this is ready for the chairs to forward along to the AD/IESG per section 2 of RFC7120. Request Description: Early Allocation Request Which

Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number.

n 2, 2020, at 10:21 AM, Tero Kivinen wrote: > > Christian Hopps writes: >> Dear ipsecme Chairs, >> >> This request is inline with the guidelines as set forth in RFC7120 >> (https://tools.ietf.org/html/rfc7120) >> >> I would like to request early all

[IPsec] Some cosmetic cleanup to IPTFS draft.

Hi Folks, Valery has indicated in private thread as a pre-WGLC comment, that as the IP-TFS encapsulation can be used for purposes other than IP-TFS we should mention that, and rename a couple items so that future derivative work doesn't seem "hackish". These changes don't change the draft or

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

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

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] 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] [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: &

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

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

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

[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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

  1   2   >