Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
Suresh Krishnan <suresh.krishnan@ericsson.com> Fri, 02 October 2015 04:08 UTC
Return-Path: <suresh.krishnan@ericsson.com>
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 998D91ACD17; Thu, 1 Oct 2015 21:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 l0o3wDr4clJs; Thu, 1 Oct 2015 21:08:50 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FA61ACD11; Thu, 1 Oct 2015 21:08:49 -0700 (PDT)
X-AuditID: c6180641-f792c6d00000686a-76-560d979789ca
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9C.7E.26730.7979D065; Thu, 1 Oct 2015 22:29:12 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 00:08:48 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Thread-Topic: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
Thread-Index: AQHQ+90XGTaaybntuU+HziqlvMWDDQ==
Date: Fri, 02 Oct 2015 04:08:47 +0000
Message-ID: <E87B771635882B4BA20096B589152EF63A9799DE@eusaamb107.ericsson.se>
References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <E87B771635882B4BA20096B589152EF63A97724C@eusaamb107.ericsson.se> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXRPgu6M6bxhButNLc49vMxkcejaT0aL 96e+sFt0r/7FbjHjz0Rmi6MPF7BaTN97jd2B3ePV/QusHmu7r7J5LFnykymAOYrLJiU1J7Ms tUjfLoErY87Zm4wF6+wrZu65ydLAeMO4i5GTQ0LARGL9y0mMELaYxIV769m6GLk4hASOMkoc 2X6dHcJZxigx5Vs3C0gVG1DHhp2fmUBsEYEQiTnvzrOAFDEL9DFJvNm5gg0kISyQInGpYwpU UarEituT2CBsPYl5E3eDxVkEVCTunWxgB7F5BXwl+je9ZoHYdoRRYtODN2AJRqCbvp9aA9bA LCAucevJfCaIWwUkluw5zwxhi0q8fPyPFcJWkvj4ez47RL2OxILdn9ggbG2JZQtfM0MsE5Q4 OfMJywRG0VlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGW5iBEbTMQk2xx2MCz5ZHmIU4GBU 4uFdUMIbJsSaWFZcmXuIUZqDRUmcd96M+6FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPtU khkEL02cbafUu8BwiXm1387Ubyy7jy2erRqj9z2hReqQ5+QzwbpuM16uet0XEjtl9sm/ekeP 9DCbNW1imrApXFz7yqvuu/ah+y/khUtp3lveZ37EOlPDYNoXs+87Lm3tuO82N93ZvfTi270P GXI9/xS9uXmKtyLoTM21OR927Ju63fpT8RYlluKMREMt5qLiRABDYuSChwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/sadczIVy2a98rMuGYyqbYfBRGKs>
Cc: "draft-ietf-conex-destopt.ad@ietf.org" <draft-ietf-conex-destopt.ad@ietf.org>, "conex-chairs@ietf.org" <conex-chairs@ietf.org>, The IESG <iesg@ietf.org>, "conex@ietf.org" <conex@ietf.org>, "draft-ietf-conex-destopt@ietf.org" <draft-ietf-conex-destopt@ietf.org>
Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 04:08:52 -0000
Hi Bob, Thanks for your clarification. Since the security section seems to potentially have some dependence on the text needed for audit to address Robert's Gen-ART review, is it possible for you and Mirja to work offline and agree to some text before presenting it to the IESG? Thanks Suresh On 10/01/2015 06:06 PM, Bob Briscoe wrote: > Stephen, Suresh, > > As the person that contributed some of the text for this IPsec section, > I can see what's happened during the evolution of the doc... > > In section 4 it says > > CDO MUST be placed as the first option in the destination option > header before the AH and/or ESP (if present). IPsec Authentication > Header (AH) MAY be used to verify that the CDO has not been modified. > > We started out writing Section 7 "Compatibility with use of IPsec" to > answering the question: > "What if IPsec is being used; how do we ensure ConEx is still visible?" > The answer was the above rule about placing CDO before AH and/or ESP. > > In the process, we showed how endpoints that were already authenticating > their IP headers with IPsec would automatically get coverage for the > ConEx header. By some perverse document evolution process, this has become: > > [Old] > > If the transport network cannot be trusted, IPsec Authentication > should be used to ensure integrity of the ConEx information. > > So I suggest the following change: > > [Proposed] > > 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. > > Actually, both parts of the subsequent sentence are wrong as well: > > [Old] > > 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. > > a) Removing ConEx marks would make audit ignore those packets, not drop > them. > b) And It's not hard to design a protocol for the sender to detect > tampering with ConEx information. > > So I suggest instead: > > [Proposed] > A network-based attacker could alter ConEx information to fool an audit > function in a downstream network into discarding packets. An attack on > one network from another by changing an immutable field can be traced, > so it would be unlikely givennetwork operators care about their > reputation.Nonetheless, if ConEx information was being altered within a > network, IPsec AH or other more stealthy e2e integrity checks could be > useful tools to help pin-point the attack location. > > No need to say this, but a similar attack is already possible: decrement > TTL in one network to cause another network to drop packets. This is > less easy to trace too, because it uses a mutable field. > > > BTW, I designed the precursor to ConEx (re-ECN) to make it possible for > networks to identify other rogue networks mounting such attacks, without > needing e2e authentication. But all the inter-network security only > works with ECN, not drop. When we decided to use ConEx to expose drop as > well as ECN, I couldn't make the drop-based aspects support these nice > security properties. That is admitted in conex-abstract-mech. But the > ECN side of ConEx still supports all the inter-domain security. None of > the inter-domain security techniques are written in the ConEx drafts, > but they're in my PhD thesis, and referenced from conex-abstract-mech > Security Considerations. > > > > > Bob > > > > On 01/10/15 09:31, Stephen Farrell wrote: >> Hiya, >> >> On 01/10/15 04:52, Suresh Krishnan wrote: >>> Hi Stephen, >>> Thanks for your comments. Please find responses inline >>> >>> On 09/30/2015 08:06 PM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-conex-destopt-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/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> - section 7: "If the transport network cannot be trusted, IPsec >>>> Authentication should be used to ensure integrity of the ConEx >>>> information." Hmm. Transport networks cannot be trusted so the >>>> first condition is always met. That means you are saying IPsec >>>> should be used. I don't see how the key management required is >>>> going to happen and even if it did, would that affect conex >>>> calculations? I'm ok with an experiment on that basis though, >>>> but it'd be better if the real relationship between this and IPsec >>>> were more fully fleshed out somewhere as part of the experiment. >>> I am not sure if the form of key management chosen would affect the >>> conex calculations at all. >> My point is that the key management implied here is basically not >> going to happen. That means IPsec will not be used and hence conex >> calculations will need to take into account the potential for routers >> to mess with the CDO. >> >> And I think the text of this would be better if it recognised the >> improbability of IPsec being used in the wild, or else spoke to how >> one could arrange experiments so that use of IPsec is more likely. >> >> Cheers, >> S. >> >>> I did read RFC5406 and I am still not sure >>> what can be said here about key management. I would really appreciate >>> some pointers/suggestions/text here. >>> >>>> - The secdir review [1] touches on similar issues. I'm not sure if >>>> that got a response, but it raises a good point that seems to me to >>>> deserve a response. >>>> >>>> [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html >>> I have added the following text in the Security Considerations section >>> of my local copy. Will submit this version after the telechat will check >>> with Robert. There is one item pending regarding audit in the Gen-ART >>> review and that may end up affecting this text. >>> >>> This document does not define how audit mechanisms work in protocols >>> that use this option and how those protocols can protect themselves >>> from likely attacks. This option MUST only be used alongside >>> protocols that define the audit mechanisms and the means for >>> protecting against likely attacks on such mechanisms. >>> >>> Thanks >>> Suresh >>> >>> >>> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >
- [conex] Stephen Farrell's No Objection on draft-i… Stephen Farrell
- Re: [conex] Stephen Farrell's No Objection on dra… Suresh Krishnan
- Re: [conex] Stephen Farrell's No Objection on dra… Stephen Farrell
- Re: [conex] Stephen Farrell's No Objection on dra… Bob Briscoe
- Re: [conex] Stephen Farrell's No Objection on dra… Suresh Krishnan
- Re: [conex] Stephen Farrell's No Objection on dra… Suresh Krishnan
- Re: [conex] Stephen Farrell's No Objection on dra… Bob Briscoe
- Re: [conex] Stephen Farrell's No Objection on dra… Stephen Farrell
- Re: [conex] Stephen Farrell's No Objection on dra… Bob Briscoe
- Re: [conex] Stephen Farrell's No Objection on dra… Stephen Farrell
- Re: [conex] Stephen Farrell's No Objection on dra… Mirja Kühlewind
- Re: [conex] Stephen Farrell's No Objection on dra… Stephen Farrell