Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
Bob Briscoe <ietf@bobbriscoe.net> Fri, 02 October 2015 08:21 UTC
Return-Path: <ietf@bobbriscoe.net>
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 9CF6E1A1A4C; Fri, 2 Oct 2015 01:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0QVme0uaAHwc; Fri, 2 Oct 2015 01:21:12 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869171A1A45; Fri, 2 Oct 2015 01:21:12 -0700 (PDT)
Received: from 26.226.114.87.dyn.plus.net ([87.114.226.26]:50964 helo=[192.168.0.15]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <ietf@bobbriscoe.net>) id 1ZhvaX-0005Up-HC; Fri, 02 Oct 2015 09:21:09 +0100
To: Suresh Krishnan <suresh.krishnan@ericsson.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <E87B771635882B4BA20096B589152EF63A97724C@eusaamb107.ericsson.se> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> <E87B771635882B4BA20096B589152EF63A9799DE@eusaamb107.ericsson.se>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <560E3E75.1060402@bobbriscoe.net>
Date: Fri, 02 Oct 2015 09:21:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <E87B771635882B4BA20096B589152EF63A9799DE@eusaamb107.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/T7lmAdGAPhx9_ovezSmxC9_sG8w>
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 08:21:15 -0000
Suresh, Sure - if Mirja is OK with that too. Bob On 02/10/15 05:08, Suresh Krishnan wrote: > 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/ -- ________________________________________________________________ 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