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

2022-08-24 Thread Christian Hopps
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 limit vs.

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

2022-08-24 Thread Christian Hopps
"Eric Vyncke (evyncke)" writes: Chris, The -17 version indeed addresses one of the 4 DISCUSS points, namely the hop limit vs. TTL. Thank you for this. I am far from being convinced that the added text about ICMP handling is rock solid though. While I cannot point a specific issue, I fear th

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

2022-08-24 Thread Eric Vyncke (evyncke)
Chris, The -17 version indeed addresses one of the 4 DISCUSS points, namely the hop limit vs. TTL. Thank you for this. I am far from being convinced that the added text about ICMP handling is rock solid though. While I cannot point a specific issue, I fear that aggregating and fragmenting inne

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

2022-08-24 Thread Christian Hopps
> 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 number must be requested to the IANA. >> >> As I pointed

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

2022-08-24 Thread Christian Hopps
> 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 ESP

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

2022-08-24 Thread Erik Kline
> > 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 ESP has a Next Header field which contains indicates what > t

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

2022-08-24 Thread Christian Hopps
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 at their fi

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

2022-08-24 Thread Warren Kumari
On Wed, Aug 24 2022 at 8:35 PM, Christian Hopps wrote: > 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

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

2022-08-24 Thread Christian Hopps
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)

2022-08-24 Thread Christian Hopps
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 understand

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

2022-08-24 Thread Warren Kumari
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 understand what "full admin control over the networ

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

2022-08-24 Thread Christian Hopps
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 reposit

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

2022-08-24 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work 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

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

2022-08-24 Thread Christian Hopps
Éric Vyncke via Datatracker writes: -- DISCUSS: -- ## DISCUSS ### Section 2.2.6 Please also mention hop-limit and RFC 8200. ### Absence of ICMP considerati

[IPsec] Robert Wilton's Discuss on draft-ietf-ipsecme-yang-iptfs-09: (with DISCUSS and COMMENT)

2022-08-24 Thread Robert Wilton via Datatracker
Robert Wilton has entered the following ballot position for draft-ietf-ipsecme-yang-iptfs-09: 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 to h

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

2022-08-24 Thread Christian Hopps
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 RF

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

2022-08-24 Thread Christian Hopps
> 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 m

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

2022-08-24 Thread Christian Hopps
> 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 r

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

2022-08-24 Thread Christian Hopps
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 case,

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

2022-08-24 Thread Christian Hopps
> 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 control" is a necessary prerequisite to mitigate/ma

Re: [IPsec] [Int-dir] Intdir telechat review of draft-ietf-ipsecme-iptfs-13

2022-08-24 Thread Eric Vyncke (evyncke)
Thank you, As you may have seen, I have referred to your review when balloting on this I-D. Regards -éric On 19/08/2022, 00:49, "Int-dir on behalf of Tatuya Jinmei via Datatracker" wrote: Reviewer: Tatuya Jinmei Review result: Ready I've reviewed version 13 of draft-ietf-ipsecm

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

2022-08-24 Thread Christian Hopps
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 separa

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

2022-08-24 Thread Lars Eggert
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 control" is a necessary prerequisite to mitigate/manage issues, but not a solution in itself. This CBR ESP tunnel is

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

2022-08-24 Thread Lars Eggert
Hi, On 2022-8-23, at 19:56, Christian Hopps wrote: > 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 alo

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

2022-08-24 Thread Lars Eggert
Hi Christian, On 2022-8-23, at 18:57, Christian Hopps wrote: >> ### Section 2.4.1, paragraph 3 >> ``` >> For similar reasons as given in [RFC7510] the non-congestion- >> controlled mode should only be used where the user has full >> administrative control over the path the tunnel will