From nobody Fri Jan 8 07:49:20 2016 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042091A8AA4; Fri, 8 Jan 2016 07:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCPkZbEze2Gw; Fri, 8 Jan 2016 07:49:12 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724261A8A9B; Fri, 8 Jan 2016 07:49:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B738CD930A; Fri, 8 Jan 2016 16:49:10 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PRF9Zqf5-yuP; Fri, 8 Jan 2016 16:49:10 +0100 (MET) Received: from [192.168.178.33] (x4d02e89e.dyn.telefonica.de [77.2.232.158]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BF9D7D9303; Fri, 8 Jan 2016 16:49:09 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <5672A409.5000609@bobbriscoe.net> Date: Fri, 8 Jan 2016 16:49:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <853E0F06-E6AE-4311-9640-31750DB0FA6A@tik.ee.ethz.ch> References: <20150930192253.28856.7833.idtracker@ietfa.amsl.com> <560D469F.4050902@bobbriscoe.net> <5672A409.5000609@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex@ietf.org" , Kathleen Moriarty , The IESG , "conex-chairs@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:49:17 -0000 Hi Suresh, hi Bob, hi Kathleen, first of all happy new year! @Kathleen: not exactly sure which bit you are taking about but I=E2=80=99v= e now applied all changes for the IPSec section Bob proposed below. = However, I don=E2=80=99t think there are actual issues on = confidentiality itself because the ConEx information is meant to be read = by the network (however it should just not be altered) and a decision to = encrypt or not is independent of ConEx. The only important thing = probably is, that if you choose to encrypt, ConEx still works and = that=E2=80=99s now clarified I believe. Other than that, I removed section 6 on auditing as discuss at the lats = IETF meeting (@Bob: we did NOT submit an update since we discuss this.) = However, based on our discussion I have slightly extended the paragraph = that we already had on credits in section 4: OLD: A transport sends credits prior to the occurrence of congestion (loss or ECN-CE marks) and the amount of credits should cover the congestion risk. This is further specified in [I-D.ietf-conex-abstract-mech] and described in detail for the case of TCP in [I-D.ietf-conex-tcp-modifications]. Note, the maximum congestion risk is that all packets in flight get lost or ECN marked. NEW: The credit signal represents potential for congestion. If a congestion event occurs, a corresponding amount of credit is = consumed, as outlined in . A ConEx-enabled sender SHOULD, therefore, signal sufficient credit = in advance to any congestion event to cover the (estimated maximum) amount of lost or = CE-marked bytes that could occur in such a congestion event. This estmation depends = on the heuristics=20 used and aggressiveness of the sender whening deciding about the = apropriate sending rate (congestion control). Note, the maximum congestion risk is that all = packets in flight get lost or CE-marked, and therefore this would be the most = conservative estimation for the congestion risk. After a congestion event, if the sender intends to = take the same risk again, it just needs to replace the consumed credit as = non-consumed credit does not expire. For the case of TCP, this is described in = detail in . Let me know if that=E2=80=99s okay/sufficient for you, or if I need to = add more or potentially even remove some stuff again! I also added Bob as an author. Mirja > Am 17.12.2015 um 13:01 schrieb Bob Briscoe : >=20 > Kathleen, Suresh, >=20 > I've tried to reload state to get this sorted (I had to check back = over the last 4 sets of diffs)... >=20 > Kathleen's right - the encryption text shouldn't have been removed. I = thought we merely agreed it needed to clarify that it was talking about = where to put the CDO to ensure it is not encrypted, if IPsec is being = used to encrypt other data. >=20 > Reading the IPSec section afresh, I could not make sense of it. The = logical flow is missing - it's not clear which parts of each para are = explaining a problem, and which parts are solving the problem. >=20 > Here's my attempts to fix this: >=20 > OLD: >=20 > If the endpoints are using the IPsec Authentication Header (AH) > [RFC4302] to detect alteration of IP headers along the path, AH will > also ensure the e2e integrity of the CDO header. A network-based > attacker could alter ConEx information to fool an audit function in = a > downstream network into discarding packets. However, other existing > attacks from one network on another such a TTL expiry attacks are > more damaging (because ConEx audit discards silently) and less > traceable (because TTL is meant to change, whereas CDO is not). >=20 > NEW; >=20 > A network-based > attacker could alter ConEx information to fool an audit function in = a > downstream network into discarding packets. > If the endpoints are using the IPsec Authentication Header (AH) > [RFC4302] to detect alteration of IP headers along the path, AH will > also detect alteration of the CDO header. Nonetheless, AH protection > will rarely need to be introduced for ConEx, because attacks by one > network on another are rare if they are traceable. Other known > attacks from one network on another such a TTL expiry attacks are > more damaging to the innocent network (because ConEx audit discards = silently) and less > traceable (because TTL is meant to change, whereas CDO is not). >=20 > REASONING: > Stated the current position and the problem before the solution. > AH does not ensure integrity, it only detects lack of integrity. > Added sentence to explain why we're only talking about existing use of = AH, not adding it, which also better justifies the last sentence, which = Stephen Farrell didn't really like, but grudgingly accepted. > s/existing/known/ to avoid implying networks are routinely attacking = other networks with TTL expiry attacks. > Added "to the innocent network", to make it clear that the damage = being discussed is the shift of blame to another network, not the = resultant lack of e2e delivery. >=20 > OLD: >=20 > Inside an IPv6 packet, a Destination Option header can be placed in > two possible positions, either before the Routing header or after = the > ESP/AH headers as described in Section 4.1 of [RFC2460]. When the > CDO is placed in the destination option header before the AH and/or > ESP, it is not encrypted in transport mode [RFC4301]. Otherwise, if > the CDO were placed in the latter position and an ESP header was = used > with encryption, the CDO cannot be viewed and interpreted by ConEx- > aware intermediate nodes effectively rendering it useless. >=20 >=20 > NEW; >=20 > Section 4 specifies that CDO is placed in the destination option = header > before the AH and/or ESP headers so that ConEx information remains > in the clear if ESP is being used to encrypt other transmitted = information > in transport mode [RFC4301]. > Inside an IPv6 packet, a Destination Option header can be placed in > two possible positions, either before the Routing header or after = the > ESP/AH headers as described in Section 4.1 of [RFC2460]. If > the CDO were placed in the latter position and an ESP header was = used > with encryption, ConEx-aware intermediate nodes would not > be able to view and interpret the CDO, effectively rendering it = useless. >=20 > REASONING: > Stated the current position and the problem before the solution. > Kept the sentence "an ESP header was used with encryption" to exclude = the null encryption case. >=20 >=20 > 6. Audit > While I had ConEx state loaded in my brain, I also checked the new = Audit section. >=20 > I thought we agreed we only needed a couple of these sentences in = section 3 of this doc, not a whole section. > All that has to be done is to specify what will be considered = sufficient L, E and C signals (another way of saying this is to specify = the semantics that an audit would reasonably be expected to enforce). > It doesn't have to define what an audit device is or does. >=20 > Here's a reminder of the para in conex-abstract-mech [RFC7713-to-be] = that this spec has to address: > " The general goal of an auditor is to make sure that any = ConEx-enabled > traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit > signals. A concrete definition of the ConEx protocol MUST define > what sufficient means. > " > You seem to be getting hung up on defining "audit". You only have to = define "sufficient". You don't even have to mention audit. >=20 > IMO, the required definitional sentences should be placed within = section 4, not in an audit section. >=20 >=20 > > If, despite the above, you do still want an audit section, I started = correcting it below, before I realised it shouldn't be there at all. >=20 > Move these two sentences to the start of the section: > " This > document does not mandate a particular audit design. Implementation > considerations are further discussed in [I-D.wagner-conex-audit]. > " >=20 > OLD: > An audit element shall be a shadow device in the network, i.e. its > presence should not be detectable for well-behaving senders. > NEW: > An audit element will typically be a stealth device in the network, > i.e. it will not need to notify end systems that discards are due to = audit failure. >=20 > s/senders correctly signals/ > /senders correctly signal/ >=20 > OLD: > For this, the audit > element has to maintain state for any active ConEx-enabled flow. > Flows must be audited independently, as there are no dependencies. > NEW: > For this, the audit > element is likely to have to maintain state for at least a sample of = active ConEx-enabled flows. > REASONING: > This section is meant to suggest, not mandate, a design. > There is no reason to mandate that flows have to be audited = independently - so sentence removed. >=20 > DELETE this last para: > The CDO MUST only be used alongside protocols that provide a way to > audit loss in the network. Any protocol specification that uses the > CDO MUST define how an audit device can detect loss on the forward > path (e.g. sequence number monitoring) and the means for protecting > against likely attacks on such mechanisms. > REASONING: > conex-abstract-mech already sets all the requirements on other docs = that address this point. > In particular, the above para contradicts the point in = conex-abstract-mech that even if the fields of a transport protocol that = reveal losses are invisible to an audit function, there are still = reasonable scenarios where audit will work (the "Predominant bottleneck = loss auditing" case). >=20 > >=20 >=20 >=20 > Bob >=20 > On 16/12/15 14:08, Kathleen Moriarty wrote: >> Hi Suresh, >>=20 >> On Mon, Dec 14, 2015 at 11:27 PM, Suresh Krishnan >> wrote: >>> Hi Kathleen, >>> I added the text to address the DISCUSSes from you and Stephen. = But Mirja >>> and Bob were in the process of reworking text concerning audit and = that might >>> lead to some changes to this text. That is why the text has been = removed. I >>> am waiting for the new text from Bob/Mirja to send the draft = further. >> My leave may start sooner than planned, so if it is possible to get >> this wrapped up today, that would be great. I don't want this to get >> held up while I am on leave and am not sure when that will start, >> sometime int he next 1-2 weeks. >>=20 >> Thanks! >> Kathleen >>=20 >>> Thanks >>> Suresh >>>=20 >>> On 12/14/2015 09:56 PM, Kathleen Moriarty wrote: >>>> I see the diff has the text added then removed on confidentiality, = but >>>> don't see why it was removed. I'd like to see if we can wrap this = up, >>>> Can you explain why the change that was requested was removed? >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> On Thu, Oct 1, 2015 at 10:43 AM, Bob Briscoe = wrote: >>>>> Suresh, Kathleen, >>>>>=20 >>>>> (I'm jumping in because I contributed this IPsec section = originally) >>>>>=20 >>>>> I think the new sentence about encryption is confusing. It talks = about >>>>> authentication of ConEx information, then it says "similarly = confidentiality >>>>> of transmitted information might be desired". It needs to be = clearer that >>>>> "transmitted information" means the rest of the packet, not the = ConEx >>>>> information. Suggested improvements inline... >>>>>=20 >>>>>=20 >>>>> On 01/10/15 02:41, Suresh Krishnan wrote: >>>>>> Hi Kathleen, >>>>>> Thanks a lot for your comments. Please find responses = inline. >>>>>>=20 >>>>>>=20 >>>>>> On 09/30/2015 03:22 PM, Kathleen Moriarty wrote: >>>>>>> Kathleen Moriarty has entered the following ballot position for >>>>>>> draft-ietf-conex-destopt-09: Discuss >>>>>>>=20 >>>>>>> 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.) >>>>>>>=20 >>>>>>>=20 >>>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>=20 >>>>>>>=20 >>>>>>> The document, along with other ballot positions, can be found = here: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> DISCUSS: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> I think this should be easy to address, but wanted to discuss = options for >>>>>>> the text in section 7. Since there is text that says IPsec >>>>>>> Authentication should be used when integrity protection and the = section >>>>>>> goes on to also discuss encryption, shouldn't there be a similar >>>>>>> statement that says IPsec encryption should be used when there = is a need >>>>>>> to protect confidentiality? >>>>>> Yes. We were worried more about the authentication because = tampering of >>>>>> the packet to scrub the markings would cause audit devices to = penalize >>>>>> the connection. Encryption on the other hand would be = counterproductive >>>>>> as the intermediate nodes would be unable to observe the = markings. >>>>>>=20 >>>>>>> Also, in reading this, I think because of the selected wording, = I was >>>>>>> thinking that it wasn't clear enough on the need/recommendation = for >>>>>>> authentication or encryption with IPsec since there are options = for both >>>>>>> to be set to NULL/none. You can have a NULL cipher-suite and = you can >>>>>>> also have authentication set to none to allow for opportunistic = security >>>>>>> negotiations (fairly new RFC for the latter). There's no need = to mention >>>>>>> these options explicitly, but rather to make it clear that IPsec = can be >>>>>>> used to provide authentication and encryption. So I think one = additional >>>>>>> sentence and some possible rewording in this section would be = helpful. >>>>>> I have added a new sentence about encryption and reworded some of = the >>>>>> text to clarify. Does this text change work for you? >>>>>>=20 >>>>>> OLD: >>>>>>=20 >>>>>> If the transport network cannot be trusted, IPsec Authentication >>>>>> should be used to ensure integrity of the ConEx information. If = an >>>>>> attacker would be able to remove the ConEx marks, this could = cause an >>>>>> audit device to penalize the respective connection, while the = sender >>>>>> cannot easily detect that ConEx information is missing. >>>>>>=20 >>>>>> In IPv6 a Destination Option header can be placed in two possible >>>>>> position in the order of possible headers, either before the = Routing >>>>>> header or after the Encapsulating Security Payload (ESP) header >>>>>> [RFC2460]. As the CDO is placed in the destination option header >>>>>> before the AH and/or ESP, it is not encrypted in transport mode >>>>>> [RFC4301]. Otherwise, if the CDO were placed in the latter = position >>>>>> and an ESP header were used, the CDO would also be encrypted and >>>>>> could not be interpreted by ConEx-aware devices. >>>>>>=20 >>>>>> NEW: >>>>>>=20 >>>>>> If the transport network cannot be trusted, the IPsec = Authentication >>>>>> Header (AH) [RFC4302] should be used to ensure integrity of the = ConEx >>>>>> information. >>>>> I suggest this is stated the other way round: >>>>>=20 >>>>> If the transport network cannot be trusted, to ensure integrity of = the ConEx >>>>> information the IPsec Authentication Header (AH) [RFC4302] should = be used. >>>>>=20 >>>>>=20 >>>>>> If an attacker would be able to remove the ConEx marks, >>>>>> this could cause an audit device to penalize the respective = connection, >>>>>> while the sender cannot easily detect that ConEx information is = missing. >>>>>=20 >>>>>> Similarly, if confidentiality of the transmitted information is = desired, >>>>>> the IPsec Encapsulating Security Payload (ESP) [RFC4303] should = be used. >>>>> Suggest replace above sentence with: >>>>>=20 >>>>> If confidentiality of the transmitted packet is desired, >>>>> the IPsec Encapsulating Security Payload (ESP) [RFC4303] can be = used, >>>>> However, the CDO header is intended to be visible to >>>>> devices along the path, therefore it will need to be located so = that it is >>>>> not >>>>> encrypted as well. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Inside an IPv6 packet, a Destination Option header can be placed = in two >>>>>> possible positions, either before the Routing header or after the = ESP/AH >>>>>> headers as described in Section 4.1 of [RFC2460]. When the CDO = is >>>>>> placed in the destination option header before the AH and/or ESP, = it is >>>>>> not encrypted in transport mode [RFC4301]. Otherwise, if the CDO = were >>>>>> placed in the latter position and an ESP header was used with >>>>>> encryption, the CDO cannot be viewed and interpreted by = ConEx-aware >>>>>> intermediate nodes effectively rendering it useless. >>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> For the Security Considerations section, I'd just ask that you = add in >>>>>>> "IPsec" when AH and ESP are first mentioned so this is clear. >>>>>> Does the above wording change work to resolve this as well? >>>>>>=20 >>>>>> Cheers >>>>>> Suresh >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> conex mailing list >>>>>> conex@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/conex >>>>>=20 >>>>> -- >>>>> ________________________________________________________________ >>>>> Bob Briscoe http://bobbriscoe.net/ >>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ From nobody Mon Jan 11 01:22:22 2016 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AFB1A8869; Mon, 11 Jan 2016 01:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZL-ci2tEMdL; Mon, 11 Jan 2016 01:22:16 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50FE91A8850; Mon, 11 Jan 2016 01:22:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 65613D940D; Mon, 11 Jan 2016 10:22:14 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lzyb7-sniB+w; Mon, 11 Jan 2016 10:22:14 +0100 (MET) Received: from [192.168.178.33] (x4d02cf37.dyn.telefonica.de [77.2.207.55]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 68693D930B; Mon, 11 Jan 2016 10:22:13 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 11 Jan 2016 10:22:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150930192253.28856.7833.idtracker@ietfa.amsl.com> <560D469F.4050902@bobbriscoe.net> <5672A409.5000609@bobbriscoe.net> <853E0F06-E6AE-4311-9640-31750DB0FA6A@tik.ee.ethz.ch> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex@ietf.org" , The IESG , "conex-chairs@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 09:22:21 -0000 Thanks and all the best! > Am 11.01.2016 um 01:24 schrieb Kathleen Moriarty = : >=20 > Mirja, Suresh, & Bob, >=20 > Thank you for making the updates. I'll clear my discuss now and trust > that the changes will be in the next updated version. I'm overdue at > this point, so just in case, I don't want to hold your draft up while > waiting to see the actual changes int he draft. >=20 > Best regards, > Kathleen >=20 > On Fri, Jan 8, 2016 at 10:49 AM, Mirja K=C3=BChlewind > wrote: >> Hi Suresh, hi Bob, hi Kathleen, >>=20 >> first of all happy new year! >>=20 >> @Kathleen: not exactly sure which bit you are taking about but I=E2=80=99= ve now applied all changes for the IPSec section Bob proposed below. = However, I don=E2=80=99t think there are actual issues on = confidentiality itself because the ConEx information is meant to be read = by the network (however it should just not be altered) and a decision to = encrypt or not is independent of ConEx. The only important thing = probably is, that if you choose to encrypt, ConEx still works and = that=E2=80=99s now clarified I believe. >>=20 >> Other than that, I removed section 6 on auditing as discuss at the = lats IETF meeting (@Bob: we did NOT submit an update since we discuss = this.) However, based on our discussion I have slightly extended the = paragraph that we already had on credits in section 4: >>=20 >> OLD: >> A transport sends credits prior to the occurrence of congestion (loss >> or ECN-CE marks) and the amount of credits should cover the >> congestion risk. This is further specified in >> [I-D.ietf-conex-abstract-mech] and described in detail for the case >> of TCP in [I-D.ietf-conex-tcp-modifications]. Note, the maximum >> congestion risk is that all packets in flight get lost or ECN = marked. >>=20 >> NEW: >> The credit signal represents potential for congestion. >> If a congestion event occurs, a corresponding amount of credit is = consumed, as >> outlined in . >> A ConEx-enabled sender SHOULD, therefore, signal sufficient credit = in advance to any >> congestion event to cover the (estimated maximum) amount of lost = or CE-marked bytes >> that could occur in such a congestion event. This estmation = depends on the heuristics >> used and aggressiveness of the sender whening deciding about the = apropriate sending rate >> (congestion control). Note, the maximum congestion risk is that = all packets in flight >> get lost or CE-marked, and therefore this would be the most = conservative estimation for the >> congestion risk. After a congestion event, if the sender intends = to take the same >> risk again, it just needs to replace the consumed credit as = non-consumed >> credit does not expire. For the case of TCP, this is described in = detail in >> . >>=20 >> Let me know if that=E2=80=99s okay/sufficient for you, or if I need = to add more or potentially even remove some stuff again! >>=20 >> I also added Bob as an author. >>=20 >> Mirja >>=20 >>=20 >>> Am 17.12.2015 um 13:01 schrieb Bob Briscoe : >>>=20 >>> Kathleen, Suresh, >>>=20 >>> I've tried to reload state to get this sorted (I had to check back = over the last 4 sets of diffs)... >>>=20 >>> Kathleen's right - the encryption text shouldn't have been removed. = I thought we merely agreed it needed to clarify that it was talking = about where to put the CDO to ensure it is not encrypted, if IPsec is = being used to encrypt other data. >>>=20 >>> Reading the IPSec section afresh, I could not make sense of it. The = logical flow is missing - it's not clear which parts of each para are = explaining a problem, and which parts are solving the problem. >>>=20 >>> Here's my attempts to fix this: >>>=20 >>> OLD: >>>=20 >>> If the endpoints are using the IPsec Authentication Header (AH) >>> [RFC4302] to detect alteration of IP headers along the path, AH = will >>> also ensure the e2e integrity of the CDO header. A network-based >>> attacker could alter ConEx information to fool an audit function in = a >>> downstream network into discarding packets. However, other = existing >>> attacks from one network on another such a TTL expiry attacks are >>> more damaging (because ConEx audit discards silently) and less >>> traceable (because TTL is meant to change, whereas CDO is not). >>>=20 >>> NEW; >>>=20 >>> A network-based >>> attacker could alter ConEx information to fool an audit function in = a >>> downstream network into discarding packets. >>> If the endpoints are using the IPsec Authentication Header (AH) >>> [RFC4302] to detect alteration of IP headers along the path, AH = will >>> also detect alteration of the CDO header. Nonetheless, AH = protection >>> will rarely need to be introduced for ConEx, because attacks by one >>> network on another are rare if they are traceable. Other known >>> attacks from one network on another such a TTL expiry attacks are >>> more damaging to the innocent network (because ConEx audit discards = silently) and less >>> traceable (because TTL is meant to change, whereas CDO is not). >>>=20 >>> REASONING: >>> Stated the current position and the problem before the solution. >>> AH does not ensure integrity, it only detects lack of integrity. >>> Added sentence to explain why we're only talking about existing use = of AH, not adding it, which also better justifies the last sentence, = which Stephen Farrell didn't really like, but grudgingly accepted. >>> s/existing/known/ to avoid implying networks are routinely attacking = other networks with TTL expiry attacks. >>> Added "to the innocent network", to make it clear that the damage = being discussed is the shift of blame to another network, not the = resultant lack of e2e delivery. >>>=20 >>> OLD: >>>=20 >>> Inside an IPv6 packet, a Destination Option header can be placed in >>> two possible positions, either before the Routing header or after = the >>> ESP/AH headers as described in Section 4.1 of [RFC2460]. When the >>> CDO is placed in the destination option header before the AH and/or >>> ESP, it is not encrypted in transport mode [RFC4301]. Otherwise, = if >>> the CDO were placed in the latter position and an ESP header was = used >>> with encryption, the CDO cannot be viewed and interpreted by ConEx- >>> aware intermediate nodes effectively rendering it useless. >>>=20 >>>=20 >>> NEW; >>>=20 >>> Section 4 specifies that CDO is placed in the destination option = header >>> before the AH and/or ESP headers so that ConEx information remains >>> in the clear if ESP is being used to encrypt other transmitted = information >>> in transport mode [RFC4301]. >>> Inside an IPv6 packet, a Destination Option header can be placed in >>> two possible positions, either before the Routing header or after = the >>> ESP/AH headers as described in Section 4.1 of [RFC2460]. If >>> the CDO were placed in the latter position and an ESP header was = used >>> with encryption, ConEx-aware intermediate nodes would not >>> be able to view and interpret the CDO, effectively rendering it = useless. >>>=20 >>> REASONING: >>> Stated the current position and the problem before the solution. >>> Kept the sentence "an ESP header was used with encryption" to = exclude the null encryption case. >>>=20 >>>=20 >>> 6. Audit >>> While I had ConEx state loaded in my brain, I also checked the new = Audit section. >>>=20 >>> I thought we agreed we only needed a couple of these sentences in = section 3 of this doc, not a whole section. >>> All that has to be done is to specify what will be considered = sufficient L, E and C signals (another way of saying this is to specify = the semantics that an audit would reasonably be expected to enforce). >>> It doesn't have to define what an audit device is or does. >>>=20 >>> Here's a reminder of the para in conex-abstract-mech [RFC7713-to-be] = that this spec has to address: >>> " The general goal of an auditor is to make sure that any = ConEx-enabled >>> traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit >>> signals. A concrete definition of the ConEx protocol MUST define >>> what sufficient means. >>> " >>> You seem to be getting hung up on defining "audit". You only have to = define "sufficient". You don't even have to mention audit. >>>=20 >>> IMO, the required definitional sentences should be placed within = section 4, not in an audit section. >>>=20 >>>=20 >>> >>> If, despite the above, you do still want an audit section, I started = correcting it below, before I realised it shouldn't be there at all. >>>=20 >>> Move these two sentences to the start of the section: >>> " This >>> document does not mandate a particular audit design. Implementation >>> considerations are further discussed in [I-D.wagner-conex-audit]. >>> " >>>=20 >>> OLD: >>> An audit element shall be a shadow device in the network, i.e. its >>> presence should not be detectable for well-behaving senders. >>> NEW: >>> An audit element will typically be a stealth device in the network, >>> i.e. it will not need to notify end systems that discards are due = to audit failure. >>>=20 >>> s/senders correctly signals/ >>> /senders correctly signal/ >>>=20 >>> OLD: >>> For this, the audit >>> element has to maintain state for any active ConEx-enabled flow. >>> Flows must be audited independently, as there are no dependencies. >>> NEW: >>> For this, the audit >>> element is likely to have to maintain state for at least a sample = of active ConEx-enabled flows. >>> REASONING: >>> This section is meant to suggest, not mandate, a design. >>> There is no reason to mandate that flows have to be audited = independently - so sentence removed. >>>=20 >>> DELETE this last para: >>> The CDO MUST only be used alongside protocols that provide a way to >>> audit loss in the network. Any protocol specification that uses = the >>> CDO MUST define how an audit device can detect loss on the forward >>> path (e.g. sequence number monitoring) and the means for protecting >>> against likely attacks on such mechanisms. >>> REASONING: >>> conex-abstract-mech already sets all the requirements on other docs = that address this point. >>> In particular, the above para contradicts the point in = conex-abstract-mech that even if the fields of a transport protocol that = reveal losses are invisible to an audit function, there are still = reasonable scenarios where audit will work (the "Predominant bottleneck = loss auditing" case). >>>=20 >>> >>>=20 >>>=20 >>>=20 >>> Bob >>>=20 >>> On 16/12/15 14:08, Kathleen Moriarty wrote: >>>> Hi Suresh, >>>>=20 >>>> On Mon, Dec 14, 2015 at 11:27 PM, Suresh Krishnan >>>> wrote: >>>>> Hi Kathleen, >>>>> I added the text to address the DISCUSSes from you and Stephen. = But Mirja >>>>> and Bob were in the process of reworking text concerning audit and = that might >>>>> lead to some changes to this text. That is why the text has been = removed. I >>>>> am waiting for the new text from Bob/Mirja to send the draft = further. >>>> My leave may start sooner than planned, so if it is possible to get >>>> this wrapped up today, that would be great. I don't want this to = get >>>> held up while I am on leave and am not sure when that will start, >>>> sometime int he next 1-2 weeks. >>>>=20 >>>> Thanks! >>>> Kathleen >>>>=20 >>>>> Thanks >>>>> Suresh >>>>>=20 >>>>> On 12/14/2015 09:56 PM, Kathleen Moriarty wrote: >>>>>> I see the diff has the text added then removed on = confidentiality, but >>>>>> don't see why it was removed. I'd like to see if we can wrap = this up, >>>>>> Can you explain why the change that was requested was removed? >>>>>>=20 >>>>>> Thanks, >>>>>> Kathleen >>>>>>=20 >>>>>> On Thu, Oct 1, 2015 at 10:43 AM, Bob Briscoe = wrote: >>>>>>> Suresh, Kathleen, >>>>>>>=20 >>>>>>> (I'm jumping in because I contributed this IPsec section = originally) >>>>>>>=20 >>>>>>> I think the new sentence about encryption is confusing. It talks = about >>>>>>> authentication of ConEx information, then it says "similarly = confidentiality >>>>>>> of transmitted information might be desired". It needs to be = clearer that >>>>>>> "transmitted information" means the rest of the packet, not the = ConEx >>>>>>> information. Suggested improvements inline... >>>>>>>=20 >>>>>>>=20 >>>>>>> On 01/10/15 02:41, Suresh Krishnan wrote: >>>>>>>> Hi Kathleen, >>>>>>>> Thanks a lot for your comments. Please find responses = inline. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 09/30/2015 03:22 PM, Kathleen Moriarty wrote: >>>>>>>>> Kathleen Moriarty has entered the following ballot position = for >>>>>>>>> draft-ietf-conex-destopt-09: Discuss >>>>>>>>>=20 >>>>>>>>> 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.) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The document, along with other ballot positions, can be found = here: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>> DISCUSS: >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>=20 >>>>>>>>> I think this should be easy to address, but wanted to discuss = options for >>>>>>>>> the text in section 7. Since there is text that says IPsec >>>>>>>>> Authentication should be used when integrity protection and = the section >>>>>>>>> goes on to also discuss encryption, shouldn't there be a = similar >>>>>>>>> statement that says IPsec encryption should be used when there = is a need >>>>>>>>> to protect confidentiality? >>>>>>>> Yes. We were worried more about the authentication because = tampering of >>>>>>>> the packet to scrub the markings would cause audit devices to = penalize >>>>>>>> the connection. Encryption on the other hand would be = counterproductive >>>>>>>> as the intermediate nodes would be unable to observe the = markings. >>>>>>>>=20 >>>>>>>>> Also, in reading this, I think because of the selected = wording, I was >>>>>>>>> thinking that it wasn't clear enough on the = need/recommendation for >>>>>>>>> authentication or encryption with IPsec since there are = options for both >>>>>>>>> to be set to NULL/none. You can have a NULL cipher-suite and = you can >>>>>>>>> also have authentication set to none to allow for = opportunistic security >>>>>>>>> negotiations (fairly new RFC for the latter). There's no need = to mention >>>>>>>>> these options explicitly, but rather to make it clear that = IPsec can be >>>>>>>>> used to provide authentication and encryption. So I think one = additional >>>>>>>>> sentence and some possible rewording in this section would be = helpful. >>>>>>>> I have added a new sentence about encryption and reworded some = of the >>>>>>>> text to clarify. Does this text change work for you? >>>>>>>>=20 >>>>>>>> OLD: >>>>>>>>=20 >>>>>>>> If the transport network cannot be trusted, IPsec = Authentication >>>>>>>> should be used to ensure integrity of the ConEx information. = If an >>>>>>>> attacker would be able to remove the ConEx marks, this could = cause an >>>>>>>> audit device to penalize the respective connection, while the = sender >>>>>>>> cannot easily detect that ConEx information is missing. >>>>>>>>=20 >>>>>>>> In IPv6 a Destination Option header can be placed in two = possible >>>>>>>> position in the order of possible headers, either before the = Routing >>>>>>>> header or after the Encapsulating Security Payload (ESP) header >>>>>>>> [RFC2460]. As the CDO is placed in the destination option = header >>>>>>>> before the AH and/or ESP, it is not encrypted in transport mode >>>>>>>> [RFC4301]. Otherwise, if the CDO were placed in the latter = position >>>>>>>> and an ESP header were used, the CDO would also be encrypted = and >>>>>>>> could not be interpreted by ConEx-aware devices. >>>>>>>>=20 >>>>>>>> NEW: >>>>>>>>=20 >>>>>>>> If the transport network cannot be trusted, the IPsec = Authentication >>>>>>>> Header (AH) [RFC4302] should be used to ensure integrity of the = ConEx >>>>>>>> information. >>>>>>> I suggest this is stated the other way round: >>>>>>>=20 >>>>>>> If the transport network cannot be trusted, to ensure integrity = of the ConEx >>>>>>> information the IPsec Authentication Header (AH) [RFC4302] = should be used. >>>>>>>=20 >>>>>>>=20 >>>>>>>> If an attacker would be able to remove the ConEx marks, >>>>>>>> this could cause an audit device to penalize the respective = connection, >>>>>>>> while the sender cannot easily detect that ConEx information is = missing. >>>>>>>=20 >>>>>>>> Similarly, if confidentiality of the transmitted information is = desired, >>>>>>>> the IPsec Encapsulating Security Payload (ESP) [RFC4303] should = be used. >>>>>>> Suggest replace above sentence with: >>>>>>>=20 >>>>>>> If confidentiality of the transmitted packet is desired, >>>>>>> the IPsec Encapsulating Security Payload (ESP) [RFC4303] can be = used, >>>>>>> However, the CDO header is intended to be visible to >>>>>>> devices along the path, therefore it will need to be located so = that it is >>>>>>> not >>>>>>> encrypted as well. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Inside an IPv6 packet, a Destination Option header can be = placed in two >>>>>>>> possible positions, either before the Routing header or after = the ESP/AH >>>>>>>> headers as described in Section 4.1 of [RFC2460]. When the CDO = is >>>>>>>> placed in the destination option header before the AH and/or = ESP, it is >>>>>>>> not encrypted in transport mode [RFC4301]. Otherwise, if the = CDO were >>>>>>>> placed in the latter position and an ESP header was used with >>>>>>>> encryption, the CDO cannot be viewed and interpreted by = ConEx-aware >>>>>>>> intermediate nodes effectively rendering it useless. >>>>>>>>=20 >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>> COMMENT: >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>=20 >>>>>>>>> For the Security Considerations section, I'd just ask that you = add in >>>>>>>>> "IPsec" when AH and ESP are first mentioned so this is clear. >>>>>>>> Does the above wording change work to resolve this as well? >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>> Suresh >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> conex mailing list >>>>>>>> conex@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/conex >>>>>>>=20 >>>>>>> -- >>>>>>> ________________________________________________________________ >>>>>>> Bob Briscoe http://bobbriscoe.net/ >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Sun Jan 17 21:18:29 2016 Return-Path: X-Original-To: conex@ietf.org Delivered-To: conex@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9A1B29E9; Sun, 17 Jan 2016 21:18:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160118051828.22769.91599.idtracker@ietfa.amsl.com> Date: Sun, 17 Jan 2016 21:18:28 -0800 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-12.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 05:18:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : IPv6 Destination Option for Congestion Exposure (ConEx) Authors : Suresh Krishnan Mirja Kuehlewind Bob Briscoe Carlos Ralli Filename : draft-ietf-conex-destopt-12.txt Pages : 13 Date : 2016-01-17 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-destopt-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-destopt-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 20 07:24:32 2016 Return-Path: X-Original-To: conex@ietf.org Delivered-To: conex@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DE31A8AE7; Wed, 20 Jan 2016 07:24:24 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120152424.12285.1288.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 07:24:24 -0800 Archived-At: Cc: conex@ietf.org, mls.ietf@gmail.com, The IESG , draft-ietf-conex-destopt@ietf.org, conex-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [conex] Document Action: 'IPv6 Destination Option for Congestion Exposure (ConEx)' to Experimental RFC (draft-ietf-conex-destopt-12.txt) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:24:24 -0000 The IESG has approved the following document: - 'IPv6 Destination Option for Congestion Exposure (ConEx)' (draft-ietf-conex-destopt-12.txt) as Experimental RFC This document is the product of the Congestion Exposure Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ Technical Summary This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The information that is represented by such markings can be used by any element on the path from a sender to a receiver, e.g., for traffic management or egress policing. This mechanism is a key element to ConEX operations, and therefore this document has been selected by the WG as one the essential specifications for ConEX. The intended status in EXPERIMENTAL (as for all ConEX specifications). Working Group Summary This document has seen 8 revision and was serval times presented in the working group session. There has been no controversial discussion about the document in the meetings or on the list. The document has received a detailed review by at least on of the experts in the working group. Document Quality This document has seen 8 revision and was serval times presented in the working group session. There has been no controversial discussion about the document in the meetings or on the list. The document has received a detailed review by at least on of the experts in the working group. Personnel Dirk Kutscher is the document shepherd for this document. Martin Stiemerling ist the responsible Area Director. From nobody Thu Jan 21 14:50:35 2016 Return-Path: X-Original-To: conex@ietf.org Delivered-To: conex@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAC81B342E; Thu, 21 Jan 2016 14:50:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160121225034.18860.69335.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 14:50:34 -0800 Archived-At: Cc: conex@ietf.org Subject: [conex] WG Action: Conclusion of Congestion Exposure (conex) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 22:50:34 -0000 The Congestion Exposure (CONEX) working group in the Transport Area has successfully finished its chartered work and is now closed. The CONEX mailing list (conex@ietf.org) will remain open. Thank you to all contributors, draft authors, and the chairs! I hope to see some experimental results out of operational networks about using the CONEX mechanisms! Regards, Martin Stiemerling TSV Transport Area Director . From nobody Mon Jan 25 09:51:37 2016 Return-Path: X-Original-To: conex@ietf.org Delivered-To: conex@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E641B37E7; Mon, 25 Jan 2016 09:51:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160125175136.30986.30850.idtracker@ietfa.amsl.com> Date: Mon, 25 Jan 2016 09:51:36 -0800 Archived-At: Cc: ipr-announce@ietf.org, conex@ietf.org Subject: [conex] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-conex-mobile X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 17:51:37 -0000 Dear Dirk Kutscher, Faisal Mir, Suresh Krishnan, Ying Zhang, Carlos Jésus Bernardos, Rolf Winter: An IPR disclosure that pertains to your Internet-Draft entitled "Mobile Communication Congestion Exposure Scenario" (draft-ietf-conex-mobile) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2742/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-conex-mobile" Thank you IETF Secretariat