Re: [IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Tero Kivinen wrote: > Murray S. Kucherawy writes: >> This posture worries me. I've no doubt that you're doing a fine job >> as the DE for the registries for which you're responsible, probably >> because you were around during IPSec's development. But what about >> your successor(s)? Will they have all of the context, background, and >> vision you have in order to continue where you eventually leave off? > Designated experts are called experts, not automation robots following > steps set in RFCs. My understanding has been that the reason we use > experts is that then we do not need to give them exact rules to > follow. Some of the RFCs gives so strict rules for experts to follow, > that there really is no point of having expert involved at all, IANA > could simply follow those same steps themselves. I very very strongly concur with Tero here. This trend to constraining experts is a problem. Either we/the IESG trusts the experts, or they don't. And, either way, if the WG is happy with the instructions, then the let the WG be. > We currently have two experts for the IPsec registries (another one was > added few years back). Also I would assume there is pool of about 5-10 > people in the IETF that could easily work as an expert on the IPsec > registries on the short notice (whether they would be willing or having > time is another issue :-) > On the other hand IPsec registries are easy, as we do have active group > of people still working on it, meaning we have active mailing list and > in case there are issues where experts are unsure, the experts can go > and verify the decisions on the mail list. Yes... if there is any doubt, the expert can come to the list with questions. I've seen other experts do this regularly. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Murray S. Kucherawy writes: > This posture worries me. I've no doubt that you're doing a fine job as the DE > for the registries for which you're responsible, probably because you were > around during IPSec's development. But what about your successor(s)? Will > they have all of the context, background, and vision you have in order to > continue where you eventually leave off? Designated experts are called experts, not automation robots following steps set in RFCs. My understanding has been that the reason we use experts is that then we do not need to give them exact rules to follow. Some of the RFCs gives so strict rules for experts to follow, that there really is no point of having expert involved at all, IANA could simply follow those same steps themselves. We currently have two experts for the IPsec registries (another one was added few years back). Also I would assume there is pool of about 5-10 people in the IETF that could easily work as an expert on the IPsec registries on the short notice (whether they would be willing or having time is another issue :-) On the other hand IPsec registries are easy, as we do have active group of people still working on it, meaning we have active mailing list and in case there are issues where experts are unsure, the experts can go and verify the decisions on the mail list. > The IETF, I'm coming to believe, has generally not done a good > enough job of succession planning. This is one place where we can > shore up that problem. > > I'll clear my DISCUSS, but I urge the working group and sponsoring > AD to give this some more thought. We currently have two experts for IPsec related IANA registries, so we have already given this some thought... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 back the code point b/c they've run out we woulbe be able to accommodate them. Thanks, Chris. > On Aug 25, 2022, at 12:35, Paul Wouters wrote: > > Indeed, they was the conclusion of the transport area at the time. I would > also prefer we could stick with that better solution, but more importantly I > don’t want this document stopped by a DISCUSS on either side of this argument. > > Paul > > Sent using a virtual keyboard on a phone > >> On Aug 25, 2022, at 12:28, Michael Richardson wrote: >> >> >>> On Aug 25, 2022, at 00:52, Erik Kline wrote: >>> I think this document needs to request a protocol number from IANA. >> >> Erik, the WG had this debate at length two+ years ago. >> >> I feel that the WG, through our AD, asked the IESG and the IntArea and >> Transport Area this specific question in a number of different ways to be >> sure. >> >> We decided not to go that way because we felt that it was a waste of a very >> scarce resource. >> >> -- >> Michael Richardson. o O ( IPv6 IøT consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
If it were me, I might add "unless all inner packets have the same marking", but I won't die on that hill. On Thu, Aug 25, 2022 at 10:57 AM Christian Hopps wrote: > > Martin Duke writes: > > > I'm not sure we've landed on a good solution with the ECN text. Two > > weeks ago I pushed Christian to do something more sophisticated with > > ECN, but realized that this is such a complicated subject that I > > wrote a draft (which, to my knowledge, no one has read): > > > > https://datatracker.ietf.org/doc/ > > draft-duke-tsvwg-ecn-aggregating-tunnels/ > > > > I am not sure what this means: > > > > "the ECN value from a congestion indicating packet should be the > > source of the copied value." > > > > So if an ECT(0) and a CE packet are in the same outer packet, the > > outer packet should be CE? But what if the inner CE packet was > > originally ECT(1) and this is an indication of minor congestion? Then > > the ECT(0) will be marked CE on egress and execute a loss response, > > which is inappropriate, even if there is no congestion whatsoever on > > the tunnel path. > > > > Or is the copied value on tunnel egress? Both? > > > > The old language, IIRC, was just to make the outer packet Not-ECT. > > This doesn't send spurious signals to the endpoints, and the only > > drawback is that the tunnel has to do a packet drop instead of using > > an ECN mark. As CBR is the preferred mode of operation here, it seems > > like this is a small price to pay. To summarize: > > > > 1) If my draft were even half-baked, it would be the best advice to > > include > > 2) Since it is not baked, I think Not-ECT (6040 "compatibility mode") > > is the best advice > > 3) The current text, IMO, is a bit ambigous, and will result in > > pathological behavior. > > I agree that compatibility mode is thing to do here, and here is the new > text: > >[[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, and there is no obvious correct way to map these >multiple values to the single outer packet ECN field value, the >tunnel ingress endpoint SHOULD operate in the "compatibility" mode >rather than the "default" mode from RFC6040. In particular this means >that the ingress (sending) endpoint of the tunnel always sets the >newly constructed outer encapsulating packet header ECN field >to Not-ECT [[RFC6040]]. > > We have a couple more ADs with ECN as a DISCUSS: > > - Lars - You wanted us to be explicit about what to do with ECN field > based on RFC6040. The propsed 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 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 RFC3168 which talks directly to handling ECN > > with IPsec security associations. We are not defining a new > > variant. I see that RFC6040 updates the RFCs we reference so we > > perhaps should add that reference here as well? > > >> > > >> It's not just adding the reference. RFC6040 specifies how ECN > > applies to tunnels, including this tunnel, so it needs to be > > followed here (or there needs to be a solid rationale/discussion > > about which aspects are not being followed and why.) > > > > > > I've changed the ECN section text on marking to: > > > > [slight grammar fix] > > > > [[RFC3168]] and [[RFC4301]] define behaviors for marking ECN > > based on the > > ingress and egress of the inner packet. These RFCs were later > > updated > > by [[RFC6040]]. The methods defined in [[RFC6040]] SHOULD be > > followed with > > the addition that if multiple inner packets are being > > encapsulated in > > an AGGFRAG mode outer packet, the ECN value from a congestion > > indicating packet should be the source of the copied value. > > > > Thanks, > > Chris. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Martin Duke writes: I'm not sure we've landed on a good solution with the ECN text. Two weeks ago I pushed Christian to do something more sophisticated with ECN, but realized that this is such a complicated subject that I wrote a draft (which, to my knowledge, no one has read): https://datatracker.ietf.org/doc/ draft-duke-tsvwg-ecn-aggregating-tunnels/ I am not sure what this means: "the ECN value from a congestion indicating packet should be the source of the copied value." So if an ECT(0) and a CE packet are in the same outer packet, the outer packet should be CE? But what if the inner CE packet was originally ECT(1) and this is an indication of minor congestion? Then the ECT(0) will be marked CE on egress and execute a loss response, which is inappropriate, even if there is no congestion whatsoever on the tunnel path. Or is the copied value on tunnel egress? Both? The old language, IIRC, was just to make the outer packet Not-ECT. This doesn't send spurious signals to the endpoints, and the only drawback is that the tunnel has to do a packet drop instead of using an ECN mark. As CBR is the preferred mode of operation here, it seems like this is a small price to pay. To summarize: 1) If my draft were even half-baked, it would be the best advice to include 2) Since it is not baked, I think Not-ECT (6040 "compatibility mode") is the best advice 3) The current text, IMO, is a bit ambigous, and will result in pathological behavior. I agree that compatibility mode is thing to do here, and here is the new text: [[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, and there is no obvious correct way to map these multiple values to the single outer packet ECN field value, the tunnel ingress endpoint SHOULD operate in the "compatibility" mode rather than the "default" mode from RFC6040. In particular this means that the ingress (sending) endpoint of the tunnel always sets the newly constructed outer encapsulating packet header ECN field to Not-ECT [[RFC6040]]. We have a couple more ADs with ECN as a DISCUSS: - Lars - You wanted us to be explicit about what to do with ECN field based on RFC6040. The propsed 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 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 RFC3168 which talks directly to handling ECN with IPsec security associations. We are not defining a new variant. I see that RFC6040 updates the RFCs we reference so we perhaps should add that reference here as well? >> >> It's not just adding the reference. RFC6040 specifies how ECN applies to tunnels, including this tunnel, so it needs to be followed here (or there needs to be a solid rationale/discussion about which aspects are not being followed and why.) > > I've changed the ECN section text on marking to: [slight grammar fix] [[RFC3168]] and [[RFC4301]] define behaviors for marking ECN based on the ingress and egress of the inner packet. These RFCs were later updated by [[RFC6040]]. The methods defined in [[RFC6040]] SHOULD be followed with the addition that if multiple inner packets are being encapsulated in an AGGFRAG mode outer packet, the ECN value from a congestion indicating packet should be the source of the copied value. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Lars Eggert's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
I'm not sure we've landed on a good solution with the ECN text. Two weeks ago I pushed Christian to do something more sophisticated with ECN, but realized that this is such a complicated subject that I wrote a draft (which, to my knowledge, no one has read): https://datatracker.ietf.org/doc/draft-duke-tsvwg-ecn-aggregating-tunnels/ I am not sure what this means: "the ECN value from a congestion indicating packet should be the source of the copied value." So if an ECT(0) and a CE packet are in the same outer packet, the outer packet should be CE? But what if the inner CE packet was originally ECT(1) and this is an indication of minor congestion? Then the ECT(0) will be marked CE on egress and execute a loss response, which is inappropriate, even if there is no congestion whatsoever on the tunnel path. Or is the copied value on tunnel egress? Both? The old language, IIRC, was just to make the outer packet Not-ECT. This doesn't send spurious signals to the endpoints, and the only drawback is that the tunnel has to do a packet drop instead of using an ECN mark. As CBR is the preferred mode of operation here, it seems like this is a small price to pay. To summarize: 1) If my draft were even half-baked, it would be the best advice to include 2) Since it is not baked, I think Not-ECT (6040 "compatibility mode") is the best advice 3) The current text, IMO, is a bit ambigous, and will result in pathological behavior. Martin On Wed, Aug 24, 2022 at 5:46 AM Christian Hopps wrote: > > 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 RFC3168 which talks directly to handling ECN with IPsec > security associations. We are not defining a new variant. I see that > RFC6040 updates the RFCs we reference so we perhaps should add that > reference here as well? > >> > >> It's not just adding the reference. RFC6040 specifies how ECN applies > to tunnels, including this tunnel, so it needs to be followed here (or > there needs to be a solid rationale/discussion about which aspects are not > being followed and why.) > > > > I've changed the ECN section text on marking to: > > [slight grammar fix] > > [[RFC3168]] and [[RFC4301]] define behaviors for marking ECN based on the > ingress and egress of the inner packet. These RFCs were later updated > by [[RFC6040]]. The methods defined in [[RFC6040]] SHOULD be followed > with > the addition that if multiple inner packets are being encapsulated in > an AGGFRAG mode outer packet, the ECN value from a congestion > indicating packet should be the source of the copied value. > > Thanks, > Chris. > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Indeed, they was the conclusion of the transport area at the time. I would also prefer we could stick with that better solution, but more importantly I don’t want this document stopped by a DISCUSS on either side of this argument. Paul Sent using a virtual keyboard on a phone > On Aug 25, 2022, at 12:28, Michael Richardson wrote: > > >> On Aug 25, 2022, at 00:52, Erik Kline wrote: >> I think this document needs to request a protocol number from IANA. > > Erik, the WG had this debate at length two+ years ago. > > I feel that the WG, through our AD, asked the IESG and the IntArea and > Transport Area this specific question in a number of different ways to be > sure. > > We decided not to go that way because we felt that it was a waste of a very > scarce resource. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec signature.asc Description: Binary data ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 think this document needs to request a protocol number from IANA. Erik, the WG had this debate at length two+ years ago. I feel that the WG, through our AD, asked the IESG and the IntArea and Transport Area this specific question in a number of different ways to be sure. We decided not to go that way because we felt that it was a waste of a very scarce resource. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 encryption [RFC4303], fully" There seem to be words missing before "fully"? This text was suggested during earlier review; however, I can no longer find it. I've now removed ", fully" for the next revision. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-iptfs-18.txt
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 Author : Christian Hopps Filename: draft-ietf-ipsecme-iptfs-18.txt Pages : 36 Date: 2022-08-25 Abstract: This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payloads. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-18 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-iptfs-17: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-ipsecme-iptfs-17: 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 refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- COMMENT: -- The first question of the shepherd writeup was not completely answered. Question 18, which is particularly relevant here, was not answered at all. Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a registry, Section 4.5 of RFC 8126 says, among other things: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. This document doesn't do so. After discussion, I'm told this is typical for IPSec registries; it's just understood that whoever might be assigned as a DE for this new registry will have the knowledge, context, and vision to do a good job. I have some broad concerns about how much our succession planning in general needs improvement, and I think this sort of thing is one aspect of that problem. I urge the WG and the AD to give this some more thought. Thanks for including Section 8. This is always helpful to read. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
On Thu, Aug 25, 2022 at 2:24 AM Tero Kivinen wrote: > Murray Kucherawy via Datatracker writes: > > -- > > DISCUSS: > > -- > > > > Section 7.1 creates an IANA registry with "Expert Review" rules. Of > such a > > registry, Section 4.5 of RFC 8126 says, among other things: > > > >The required documentation and review criteria, giving clear guidance > >to the designated expert, should be provided when defining the > >registry. > > > > This document doesn't do so. Is that guidance available somewhere else, > or > > should some be added here? > > This is common in the IPsec documents. The working group has assumed > that experts are experts and they know what to do without being > explictly instructed to do so > > As an IANA Expert for most of the IPsec related registries, I hope > that I have been able to do that job in a such way that other people > have found that good enough (at least I have not heard complains about > that). > > [...] > This posture worries me. I've no doubt that you're doing a fine job as the DE for the registries for which you're responsible, probably because you were around during IPSec's development. But what about your successor(s)? Will they have all of the context, background, and vision you have in order to continue where you eventually leave off? The IETF, I'm coming to believe, has generally not done a good enough job of succession planning. This is one place where we can shore up that problem. I'll clear my DISCUSS, but I urge the working group and sponsoring AD to give this some more thought. -MSK ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Warren Kumari 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 lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- DISCUSS: -- [ Chat with Christian Hopps on the telechat -- I explained my concerns and Christian will add some text around how to deploy this safely / some background context. Even if you are the network admin and in complete control of the network, having some "here are some things to keep in mind when deploying, like that that will ALWAYS use the configured bandwidth so make sure you will always have that free during failures and congestion and things like that..." type warnings are helpful. ] Clearing my discuss. -- COMMENT: -- Much thanks to Bo Wu for the OpsDir review, and to the authors for addressing / incorporating the comments. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] John Scudder's No Objection on draft-ietf-ipsecme-iptfs-17: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-ipsecme-iptfs-17: 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 refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- COMMENT: -- Nit: I just happened to notice this bit in the Intro: "While directly obscuring the data with encryption [RFC4303], fully" There seem to be words missing before "fully"? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- DISCUSS: -- Thanks for working on this specification. I found this spec to be a mix of transport and non-transport related topics and had to think a bit more due to lack of rational behind choices made. I would like to discuss - why there is no normative text (MUST/MUST NOT) for non-congestion controlled mode over operation in this specification that prohibits the use of non-congestion controlled mode out side of controlled environment? Indeed, the suggested text we offered to add was: "This MUST NOT be used when full admin control over the network cannot be assured." I am also supporting Lars's discuss on 3.1 ECN support. This 2nd paragraph was added to satisfy this DISCUSS, please see the latest version: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-17#section-3.1 Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
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 lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- DISCUSS: -- Thanks for working on this specification. I found this spec to be a mix of transport and non-transport related topics and had to think a bit more due to lack of rational behind choices made. I would like to discuss - why there is no normative text (MUST/MUST NOT) for non-congestion controlled mode over operation in this specification that prohibits the use of non-congestion controlled mode out side of controlled environment? I am also supporting Lars's discuss on 3.1 ECN support. -- COMMENT: -- The version of this specification changed quite frequently during the telechat review period, hence I am mentioning that I am reviewing the -17th version of this specification. I have following comments, which I believe will improve the specification if properly addressed - # Section 2.4: I would like to have rational behind the two mode of operations. what are the pros and cons and when would an implementer select one over another? if this is written somewhere else then having a point would be great benefit. # Section 2.4.1: I believe the assumption here is that the network is fully provisioned and no congestion related loss should occur hence here would not need to react to any loss. what would be source of the potential loss then? link failure only? if the loss is due to underestimation of bandwidth then 8084 need to be implemented as a last resort. It actually talks about circuit breakers in section 2.4.2.1 and somehow managed to say in addition to congestion control, the implementation that support non-congestion control mode should implement circuit breaker. This is where I am a bit lost, why is this written in section 2.4.2.1 and not in 2.4.1? is this the assumption that the implementation that have non-congestion control mode would not have congestion control mode? The failure correction due to the expected bandwidth under, where loss seems to be an indication, seems like a serious matter and but still there is no normative language requirements on the reporting the loss. I wonder how useful this could be. The last line actually makes me more confused. If ESP over TCP is in use then TCP would trigger the congestion control, thus this becomes a congestion controlled case and yes, you can then perhaps send out packets without thinking about congestion collapse. But then the assumption changes, then it becomes the case IP-TFS is expected to run over a congestion controlled transport. however, that is not the general assumption for the whole non-congestion controlled mode of operation. Here, I think we need to clarify a bit more on how to interpret the non-congestion controlled mode description. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 this specific protocol. Hi Lars, That was not required of pseudowires, I'm wondering why we are different here. We do in fact indicate that congestion reports should be enabled when implementing a circuit breaker to provide the sender with the RFC8084 required information. How sophisticated a vendor makes their circuit breakers (e.g., the types of controls they offer to the user etc), is a method of market differentiation. Normally IETF does not limit this unless it is required for protocol interoperability. If you're requiring that we give an example of a simple CB implementation for vendors incapable of figuring this out (I'm not sure how they managed to implement the rest of the protocol w/o being able to do this but anyway..)? I can add the following text if it will clear the DISCUSS. One example of a simple slow-trip circuit breaker (CB) an implementation may provide would utilize 2 values, the amount of persistent loss rate required to trip the CB and the required length of time this persistent loss rate must be seen to trip the CB. These 2 value are required configuration from the user. When the CB is tripped the tunnel traffic is disabled, and an appropriate log message or other management type alarm is triggered indicating operate intervention is required. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[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 of RFC 8126 says, among other things: > >The required documentation and review criteria, giving clear guidance >to the designated expert, should be provided when defining the >registry. > > This document doesn't do so. Is that guidance available somewhere else, or > should some be added here? This is common in the IPsec documents. The working group has assumed that experts are experts and they know what to do without being explictly instructed to do so As an IANA Expert for most of the IPsec related registries, I hope that I have been able to do that job in a such way that other people have found that good enough (at least I have not heard complains about that). For example the IKEv2 registries created in RFC4306 (https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml) are all expert review and the RFC4306 gave following instructions: -- 6. IANA Considerations This document defines a number of new field types and values where future assignments will be managed by the IANA. The following registries have been created by the IANA: IKEv2 Exchange Types (section 3.1) IKEv2 Payload Types (section 3.2) IKEv2 Transform Types (section 3.3.2) IKEv2 Transform Attribute Types (section 3.3.2) IKEv2 Encryption Transform IDs (section 3.3.2) IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) IKEv2 Integrity Algorithm Transform IDs (section 3.3.2) IKEv2 Diffie-Hellman Transform IDs (section 3.3.2) IKEv2 Identification Payload ID Types (section 3.5) IKEv2 Certificate Encodings (section 3.6) IKEv2 Authentication Method (section 3.8) IKEv2 Notify Message Types (section 3.10.1) IKEv2 Notification IPCOMP Transform IDs (section 3.10.1) IKEv2 Security Protocol Identifiers (section 3.3.1) IKEv2 Traffic Selector Types (section 3.13.1) IKEv2 Configuration Payload CFG Types (section 3.15) IKEv2 Configuration Payload Attribute Types (section 3.15.1) Note: When creating a new Transform Type, a new registry for it must be created. Changes and additions to any of those registries are by expert review. -- (i.e., that is full IANA considerations section). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Erik Kline writes: > > > > > 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 > type of packet is inside the ESP packet. It typically contains IP > Protocol Numbers, but not always. Thats why the RFC4303 above says > "chosen from the set of IP Protocol Numbers". > > I disagree. 4303 S2.6 is very clearly talking about the Protocol Numbers > registry (the example of "41 means IPv6" is one of the things that give it > away). Note that IP Protocol value 41 for ESP does NOT MEAN same thing than what is described in the RFC 2473. The payload format of the ESP is different than what is described in that RFC. ESP Tunnel mode adds other pieces to the packet in different locations. The reason 41 (and 4) where chosen to match the ESP Tunnel mode is because they do have similar use than ESP Tunnel mode, but the actual protocols are different. > I think this document needs to request a protocol number from IANA. That would be one option, but then there might be issues where someone actually tries to use this outside the ESP, and because the current specification requires things to be negotiated in the IKEv2, this is not really possible, and using this outside ESP will also break the traffic flow confidentiality completely as there is no encryption of the traffic. We could also say that if the USE_AGGFRAG is negotiated for the Child SA (ESP SA) then Next header field is ignored on recipient, and sent as zeros, and all packets inside the Child SA are going to use AGGFRAG_PAYLOAD format. We do loose some information that would be helpful when debugging configuration issues, but the protocol would still work. It would also made it harder to do future enhancements to this protocol. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 of RFC 8126 says, among other things: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. This document doesn't do so. Is that guidance available somewhere else, or should some be added here? Hi Murray, This came up during the AD review. Here was the supplied answer: ** Section 7.1. To double check, there is no more guidance to provide to the expert reviewer? It's pretty wide open what sub-type might be used in the future (could even be completely different payload encapsulations/uses etc), so we didn't see a reason to limit/guide the experts anymore here. Thanks, Chris. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
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 this specific protocol. -- Sent from a mobile device; please excuse typos. > On Aug 25, 2022, at 03:28, Christian Hopps wrote: > > 2.4.2.1. Circuit Breakers > > In additional to congestion control, implementations that support > non-congestion control mode SHOULD implement circuit breakers > [RFC8084] as a recovery method of last resort. When circuit breakers > are enabled an implementation SHOULD also enable congestion control > reports so that circuit breakers have information to act on. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Murray Kucherawy 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 lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- DISCUSS: -- Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a registry, Section 4.5 of RFC 8126 says, among other things: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. This document doesn't do so. Is that guidance available somewhere else, or should some be added here? -- COMMENT: -- The first question of the shepherd writeup was not completely answered. Question 18, which is particularly relevant here, was not answered at all. Thanks for including Section 8. This is always helpful to read. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-yang-iptfs-09: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-ipsecme-yang-iptfs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/ -- COMMENT: -- The first question of the shepherd writeup was not completely answered. Do you need BCP 14 (Section 1.1) at all? You don't seem to use it anywhere. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 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 inner packets and receiving one ICMP on the outer packet is not so trivial and some actual guidance based on actual testing would be welcome. This is 'unknown territory' AFAIK (no other aggr/frag tunnels over IP were specified/deployed before) and for a 'standards track' I-D, we need more guidance. There's nothing too scary here. - inner packet ICMP is completely independent of the IPsec tunnel, its just more inner traffic. This was perhaps too simple a description of what is happening. RFC4301 does have text relating to the transiting of ICMP traffic through an SA, but these are policies about whether to allow the traffic through the SA or not. Inner ICMP traffic is not being processed to have an affect on the SA/tunnel or not. Thanks, Chris. - outer packet ICMP is addressing the same singular ESP packets it always has. It is related to things like the size of the outer packet (PMTU) or the destination of the outer packet, etc. This is unaffected by what is encapsulated inside the ESP packet. Thus it is enough to refer back to RFC4301 here -- it really does cover all the cases. FWIW when one is implementing IP-TFS all the ICMP receive mechanics have 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 Christian Hopps" wrote: Éric Vyncke via Datatracker writes: > -- > DISCUSS: > -- > > ## DISCUSS > > ### Section 2.2.6 > > Please also mention hop-limit and RFC 8200. > > ### Absence of ICMP considerations > > Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As several > unprotected packets can be bundled together, some guidance to the implementers > will be welcome. The section has been modified to address these concerns: *** IPv4 Time-To-Live (TTL), IPv6 Hop Limit, and Tunnel errors [[RFC4301]] specifies how to modify the inner packet IPv4 TTL [[RFC0791]] or IPv6 Hop Limit [[RFC8200]]. Any errors (e.g., ICMP errors) are handled the same as with non-AGGFRAG IPsec tunnels. This applies to both the outer traffic as well as the inner traffic prior to it entering the tunnel, see [[RFC4301]]. I believe this should cover the rest of the items left in this DISCUSS ballot. Thanks, Chris. [[End of PGP Signed Part]] signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
"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 that aggregating and fragmenting inner packets and receiving one ICMP on the outer packet is not so trivial and some actual guidance based on actual testing would be welcome. This is 'unknown territory' AFAIK (no other aggr/frag tunnels over IP were specified/deployed before) and for a 'standards track' I-D, we need more guidance. There's nothing too scary here. - inner packet ICMP is completely independent of the IPsec tunnel, its just more inner traffic. - outer packet ICMP is addressing the same singular ESP packets it always has. It is related to things like the size of the outer packet (PMTU) or the destination of the outer packet, etc. This is unaffected by what is encapsulated inside the ESP packet. Thus it is enough to refer back to RFC4301 here -- it really does cover all the cases. FWIW when one is implementing IP-TFS all the ICMP receive mechanics have 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 Christian Hopps" wrote: Éric Vyncke via Datatracker writes: > -- > DISCUSS: > -- > > ## DISCUSS > > ### Section 2.2.6 > > Please also mention hop-limit and RFC 8200. > > ### Absence of ICMP considerations > > Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As several > unprotected packets can be bundled together, some guidance to the implementers > will be welcome. The section has been modified to address these concerns: *** IPv4 Time-To-Live (TTL), IPv6 Hop Limit, and Tunnel errors [[RFC4301]] specifies how to modify the inner packet IPv4 TTL [[RFC0791]] or IPv6 Hop Limit [[RFC8200]]. Any errors (e.g., ICMP errors) are handled the same as with non-AGGFRAG IPsec tunnels. This applies to both the outer traffic as well as the inner traffic prior to it entering the tunnel, see [[RFC4301]]. I believe this should cover the rest of the items left in this DISCUSS ballot. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
