Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Hitoshi Asaeda <asaeda@ieee.org> Thu, 15 March 2018 07:51 UTC
Return-Path: <asaeda@ieee.org>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4183127735 for <mboned@ietfa.amsl.com>; Thu, 15 Mar 2018 00:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com
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 DJIIzXNNcGD7 for <mboned@ietfa.amsl.com>; Thu, 15 Mar 2018 00:51:49 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F791242F5 for <mboned@ietf.org>; Thu, 15 Mar 2018 00:51:49 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id e3so2464188pga.6 for <mboned@ietf.org>; Thu, 15 Mar 2018 00:51:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nm69W1oPhDKgGgXzPmxKkB181Azzd0upFmnIGAwdgso=; b=qH79XvGiQfQ//dh+3oagu6GJ5EdrnKaOTgjzkMV7u6sM+OEQUIw6aa9F2ZxF9EbQmd PXJXaJndBAbjTIW8uG5TMftbZ4YCIrqPSmacmB21qusCRnXu3wxrHMMjJIhjKnxAsa4N mzo3xxe4kDEuGuGYL9rdSZcjqhjzw64tFBC7hsKI1FvVuHz72xw9zM4R6gFAvBlptQBQ RUQhTKbmWVLd4cuBI/g/I8+AUNi/4rsrxcY/FYhQLGfemNcui+MeUrjEzI0+yqahyz1f E8yHPY3UoTIGgZnOjLSRLzwNfAOQbWSRufWRX68mUn0KytCoJgB1NE8NwsQRp+ieCjGM zhWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nm69W1oPhDKgGgXzPmxKkB181Azzd0upFmnIGAwdgso=; b=ebDiJYFnp40C1fgTZcprpReQq4XdQ8yv24msj3P0lPJ1vYks8KEFunyc51zOHRPWad FfoqhRusMHyTB3vjE2FYEZpBsu4excKCIpDX3VZRQBz0ohYxxh+kAHVmgJdnKwvChRYz cXZncORe89n01jP72Z2Tz5sxMjVLITopcz2ZzTeqYmHYFO+JfwphEEopG80yWLEs4Qcv KlDfAbkNnsnL1XU+mjh+AXxQQAdTF9RELbF8kL+8mPcuWg4US+9BknONVfozXQfXOjoM LYQuP5S+t/n31UW97EwHujuVm9riT/G+yJY33T4KjJnWh+nKhgpZTTrRK3rhf8evUlKR yqAg==
X-Gm-Message-State: AElRT7GCb3Dgr+vBArPLW7fB7I9TO4qaWURongFVjXUdisn43dBlpEfG cAuDldEElyMgCORTpF1qza9MSw==
X-Google-Smtp-Source: AG47ELuB8cO9uE7q5SUCJAC5RL9clNQ/INlhht/MrHoBCkWBJjyul2Jrkv2ENJIsqsYJk9OFqaQGXA==
X-Received: by 10.98.3.66 with SMTP id 63mr225485pfd.177.1521100309010; Thu, 15 Mar 2018 00:51:49 -0700 (PDT)
Received: from ?IPv6:2001:200:e103:1000:821:ed44:ed12:342b? ([2001:200:e103:1000:821:ed44:ed12:342b]) by smtp.gmail.com with ESMTPSA id p6sm8727443pfg.183.2018.03.15.00.51.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 00:51:48 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Hitoshi Asaeda <asaeda@ieee.org>
In-Reply-To: <6E5478D0-6145-4EC2-8DF3-15B095271F9D@ieee.org>
Date: Thu, 15 Mar 2018 16:51:43 +0900
Cc: Eric Rescorla <ekr@rtfm.com>, draft-ietf-mboned-mtrace-v2@ietf.org, mboned@ietf.org, mboned-chairs@ietf.org, Toerless Eckert <tte@cs.fau.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87555175-04AB-424E-9FFE-C7FEAA2F0514@ieee.org>
References: <151628969901.2325.7724014542086691903.idtracker@ietfa.amsl.com> <20180119193149.GA26689@faui40p.informatik.uni-erlangen.de> <CABcZeBNDqq_5XPad76WrsrN_JS2J1iAAC068=y0Nq12SKJOQ=Q@mail.gmail.com> <20180125223335.GA16477@faui40p.informatik.uni-erlangen.de> <CABcZeBPbCJfP=VVC6irEUtbiFuQgmMCQMEUBern=kAG-KP1SQQ@mail.gmail.com> <20180126013118.GD16477@faui40p.informatik.uni-erlangen.de> <CABcZeBN5dWkn7dGZ00tw2AkGPPAdfS+C_8mrVMuB9efc4o1a9Q@mail.gmail.com> <CAHw9_iJtqpKVDgVscQ0UwZVAHbVhTJhjPsgWLkfzCk=gQoBs7g@mail.gmail.com> <B9494C22-3353-4ADF-BEF0-B1ACB785E01B@ieee.org> <CAHw9_iJBKFF_DzU3Av0TaC5+xTx6Mm6srdhWOFAsXJUY24NneQ@mail.gmail.com> <6E5478D0-6145-4EC2-8DF3-15B095271F9D@ieee.org>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/giFEoNyFBdtATsDVATJn8TFfLuk>
Subject: Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Mar 2018 07:51:55 -0000
Hi Warren, Eric, and folks, Kerry and I have been working on the security threat analysis initiated by Eric’s comments. Kerry is now doing double check for our thoughts and will post the story tomorrow, I guess. Sorry for the long delay, but please wait for a while. Thanks for your cooperation. Regards, Hitoshi > 2018/03/14 10:53, Hitoshi Asaeda <asaeda@ieee.org> wrote: > > Hi Warren, > > I have been working on the security threat analysis with Kerry but > not completed the documentation. > We will post our thoughts on the ml asap. > I’m sorry that I cannot attend this meeting at London locally, but > will try to attend via jabber. > > Regards, > > Hitoshi > > >> 2018/03/14 6:32, Warren Kumari <warren@kumari.net> wrote: >> >> It has been basically 2 weeks since the last update - can you let me >> know when I can expect progress? Will this be discussed in London? >> >> W >> >> On Wed, Feb 28, 2018 at 3:57 AM, Hitoshi Asaeda <asaeda@ieee.org> wrote: >>> Hi again, >>> >>>> 2018/02/27 8:56, Warren Kumari <warren@kumari.net> wrote: >>>> >>>> [ - IESG for clutter ] >>>> >>>> On Fri, Jan 26, 2018 at 4:58 PM, Eric Rescorla <ekr@rtfm.com> wrote: >>>>> Hi Toerless, >>>>> >>>>> I appreciate the solution thinking, but I don't want to overrotate on these >>>>> specific threats (though of course we must address them). My concern is that >>>>> if there are threats this obvious then we need a more complete threat >>>>> analysis. I.e., what are the avenues for attack with this protocol and then >>>>> what mechanisms prevent those things. The purpose of the security >>>>> considerations section is to make sure that that happens. Has someone done >>>>> that somewhere and it just didn't make it into the document? >>>> >>>> >>>> Toerless / authors, >>>> >>>> It has been around a month since this reply -- I'm hoping that the >>>> there has been more discussion and that I just fell off the thread and >>>> / or that my search foo has failed me. >>>> >>>> EKR makes good points (and holds a DISCUSS) - we need to figure out >>>> how to address them. Was there more discussions on the thread >>>> analysis? Clue bat appreciated. >>> >>> We may have to do some sort of security threat analysis and document the results, >>> along with possible remedies to address the existing threats. >>> We’ll seek comments in the ML after the authors agree on the idea. >>> >>> Best regards, >>> >>> Hitoshi >>> >>> >>>> >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> On Thu, Jan 25, 2018 at 5:31 PM, Toerless Eckert <tte@cs.fau.de> wrote: >>>>>> >>>>>> On Thu, Jan 25, 2018 at 03:08:58PM -0800, Eric Rescorla wrote: >>>>>>>> My point B.1) explicitly disables lying about the requesting address, >>>>>>>> so >>>>>>>> it is explicitly meant to prohibit amplification attacks. >>>>>>>> >>>>>>> >>>>>>> I don't see how that's true. The attack I am concerned about is that you >>>>>>> forge a *Request*, not a *Query*. And because the request indicates the >>>>>>> original >>>>>>> requester. >>>>>> >>>>>> Ah, sorry. I thought to remember that the text from you said query. >>>>>> I just replied for query messages so far. >>>>>> >>>>>>> (give or take the subnet local limitations and/or additional L2 security >>>>>>>> required to prohibit intra-l2-lying that i mentioned in my original >>>>>>>> mail). >>>>>>> >>>>>>> Sorry, I'm not seeing this. The point is that you pretend to be a router >>>>>>> that is forwarding a Request and fill in a bogus Client Address field. >>>>>>> Waht >>>>>>> stops that. >>>>>> >>>>>> In practical deployments IMHO we can only reasonable get similar solutions >>>>>> to >>>>>> what customer are also willing to deploy with PIM. For 99% deployments >>>>>> that >>>>>> is configured classificatio of interfaces as trusted/inside-clamshell or >>>>>> untrusted/user-facing, and on the untrusted interfaces you don't accept >>>>>> requests, just queries. And apply the suggested B.1 policy (Mtracev2 >>>>>> Client >>>>>> Address must be connected on receiving interface). >>>>>> >>>>>> It might still be useful to have mtrace prepared for customers protecting >>>>>> it >>>>>> with IPsec - without requiring special features in mtrace or IPsec for it. >>>>>> >>>>>> IMHO for that, we need to have one UDP port for mtrace NNI messages >>>>>> (requests), and another for UNI messages (query, response). >>>>>> That would allow customers to take a vanilla IPsec implementation and >>>>>> protect >>>>>> the mtrace NNI messages and therefore eleiminate interface clamshell >>>>>> classification. In multicast signaling we got this for free: PIM is NNI, >>>>>> IGMP/MLD UNI. Easy to distinguish for IPsec. >>>>>> >>>>>>>> My points B.1, B.2, B.3) provide solid access control mechanisms for >>>>>>>> mtrace using mechanisms that are the most widely adopted form of >>>>>>>> security >>>>>>>> in ISPs >>>>>>>> and that this option of security in mtrace should not be dismissed >>>>>>>> just >>>>>>>> because >>>>>>>> it took us so long to bring the protocol in front of IESG review even >>>>>>>> if >>>>>>>> we agree >>>>>>>> that we should have better options beyond that. >>>>>>> >>>>>>> The question is whether those options are in fact adequate. For the >>>>>>> reasons >>>>>>> above I don't believe that. >>>>>>> >>>>>>> -Ekr >>>>>> >>>>>> Cheers >>>>>> Toerless >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The other point was that better security options are something we >>>>>>>> should >>>>>>>> not >>>>>>>> invent as one-off protocol hack sinto mtrace (even if some mtrace none >>>>>>>> request/reply >>>>>>>> messages might be fun to define) but instead we should adopt solutions >>>>>>>> that are more >>>>>>>> likely in-line with existing network OAM security strategies. TLS >>>>>>>> connections, >>>>>>>> netconf/yang etc. pp. As i described in my email. >>>>>>>> >>>>>>>> Cheers >>>>>>>> toerless >>>>>>>> >>>>>>>>> -Ekr >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The most likely next step to overcome the trusted path issue between >>>>>>>>>> query initiator to query responder is to make an mtrace yang model >>>>>>>> where >>>>>>>>>> you can actually initiate an mtrace via netconf/yang, aka: replace >>>>>>>>>> the query with netconf. Like you would today just ssh into the >>>>>>>>>> LHR and run a local mtrace client there. >>>>>>>>>> >>>>>>>>>> Alas, i see no easy way to get back to support A) in a lightweight >>>>>>>>>> fashion ;-( >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> Toerless >>>>>>>>>> >>>>>>>>>> On Thu, Jan 18, 2018 at 07:34:59AM -0800, Eric Rescorla wrote: >>>>>>>>>>> Eric Rescorla has entered the following ballot position for >>>>>>>>>>> draft-ietf-mboned-mtrace-v2-22: 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/iesg/stat >>>>>>>>>> ement/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-mboned-mtrace-v2/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>> ---------- >>>>>>>>>>> DISCUSS: >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>> ---------- >>>>>>>>>>> >>>>>>>>>>> The security considerations of this document are inadequate. My >>>>>>>> review >>>>>>>>>>> turns up at least the following potential issues which do >>>>>>>>>>> not seem to be addressed or even discussed: >>>>>>>>>>> >>>>>>>>>>> - Amplification: this protocol does not appear to verify that >>>>>>>>>>> the >>>>>>>>>>> sender of the query actually owns the IP it claims. Because >>>>>>>>>>> responses are much larger than queries, this allows for an >>>>>>>>>> amplification >>>>>>>>>>> attack, especially if the client is able to send a query that >>>>>>>> elicits >>>>>>>>>>> multiple replies. One defense here would be to fill the rest >>>>>>>>>>> of the >>>>>>>>>> packet >>>>>>>>>>> with zeroes, thus somewhat reducing the amplification factor. >>>>>>>> Access >>>>>>>>>>> control would also help. >>>>>>>>>>> >>>>>>>>>>> - Forgery of responses: because the query id is so short, an >>>>>>>>>>> attacker >>>>>>>>>>> can generally produce a message which has a nontrivial chance >>>>>>>>>>> of >>>>>>>>>>> corresponding to an extant query. This could be addressed by >>>>>>>>>>> having >>>>>>>>>>> a query ID that was large and random. >>>>>>>>>>> >>>>>>>>>>> - Anyone on-path can forge responses. >>>>>>>>>>> >>>>>>>>>>> In addition, Section 9.4 seems inadequate. Isn't it generally >>>>>>>>>>> the >>>>>>>> case >>>>>>>>>> that >>>>>>>>>>> who is sending to who is sensitive? This seems like a fairly >>>>>>>>>>> serious >>>>>>>>>> privacy >>>>>>>>>>> obstacle to using this protocol at all. >>>>>>>>>>> >>>>>>>>>>> It seems like many of the issues I raise above would be fixed or >>>>>>>>>>> at >>>>>>>>>>> least mitigated by having some sort of access control mechanism. >>>>>>>>>>> I >>>>>>>>>>> understand why it might be the case that it's not practical to >>>>>>>>>>> have >>>>>>>>>>> full communication security between the links (though it would >>>>>>>>>>> of >>>>>>>>>>> course be desirable), but it's not clear to me why arbitrary >>>>>>>>>>> people >>>>>>>>>>> should be allowed to instantiate queries. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>> ---------- >>>>>>>>>>> COMMENT: >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>> ---------- >>>>>>>>>>> >>>>>>>>>>> S 1. >>>>>>>>>>> When an Mtrace2 client initiates a multicast trace, it sends >>>>>>>>>>> an >>>>>>>>>>> Mtrace2 Query packet to the LHR or RP for a multicast group >>>>>>>>>>> and, >>>>>>>>>>> >>>>>>>>>>> This seems a bit confusing as there are multiple LHRs for the >>>>>>>>>>> group. >>>>>>>>>>> Can you rephrase? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S 2.1. >>>>>>>>>>> ALL-[protocol]-ROUTERS group >>>>>>>>>>> It is a link-local multicast address for multicast routers >>>>>>>>>>> to >>>>>>>>>>> >>>>>>>>>>> This is grammatically funny. Perhaps remove "It is" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S 3. >>>>>>>>>>> additional information associated with the message. If an >>>>>>>>>>> implementation receives an unknown TLV type for the first TLV >>>>>>>>>>> in a >>>>>>>>>>> message (i.e., the header TLV), it SHOULD ignore and silently >>>>>>>> discard >>>>>>>>>>> the entire packet. If an implementation receives an unknown >>>>>>>>>>> TLV >>>>>>>> type >>>>>>>>>>> for a subsequent TLV within a message, it SHOULD ignore and >>>>>>>> silently >>>>>>>>>>> discard the entire packet. >>>>>>>>>>> >>>>>>>>>>> ISTM that these cases are handled identically so is there a >>>>>>>>>>> reason >>>>>>>>>>> not just to remove the first sentence and change the second one >>>>>>>>>>> to >>>>>>>>>>> "for any TLV"/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S 3.2.1 >>>>>>>>>>> An Mtrace2 Query is usually originated by an Mtrace2 client >>>>>>>>>>> which >>>>>>>>>>> sends an Mtrace2 Query message to the LHR. When tracing >>>>>>>>>>> towards >>>>>>>> the >>>>>>>>>>> source or the RP, the intermediate routers MUST NOT modify >>>>>>>>>>> the >>>>>>>> Query >>>>>>>>>>> message except the Type field. >>>>>>>>>>> >>>>>>>>>>> I'm not sure I follow this. Don't routers either (a) not touch >>>>>>>>>>> this >>>>>>>> at >>>>>>>>>> all >>>>>>>>>>> or (b) if they are the LHR, change Type from Query -> Request >>>>>>>>>>> and >>>>>>>> then >>>>>>>>>>> add a response block? This text seems to not really capture >>>>>>>>>>> either >>>>>>>> case. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S 3.2.4. >>>>>>>>>>> Note that Mtrace2 does not require all the routers on the >>>>>>>>>>> path >>>>>>>> to >>>>>>>>>>> have synchronized clocks in order to measure one-way >>>>>>>>>>> latency. >>>>>>>>>>> >>>>>>>>>>> It's not clear to me how one does this. Can you expand? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S 3.2.6. >>>>>>>>>>> >>>>>>>>>>> 0x01 # of the returned Standard Response Blocks >>>>>>>>>>> >>>>>>>>>>> Nit: Do you want to say 0x0001 >>>>>>>>>>> >>>>>>>>>>> Also, an example of the case covered by this section would help, >>>>>>>>>>> I >>>>>>>> think. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S 4.4. >>>>>>>>>>> It might be clearer to move this up a bit in the text as it sort >>>>>>>>>>> of >>>>>>>>>>> summarizes some cases you already covered before. It would be >>>>>>>>>>> easier >>>>>>>>>>> if it provided an overview instead. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S 5.9. >>>>>>>>>>> >>>>>>>>>>> In this case, the Mtrace2 >>>>>>>>>>> client may receive multiple Mtrace2 Replies from different >>>>>>>>>>> routers >>>>>>>>>>> along the path. When this happens, the client MUST treat >>>>>>>>>>> them as >>>>>>>> a >>>>>>>>>>> single Mtrace2 Reply message. >>>>>>>>>>> >>>>>>>>>>> Can you please describe how the client reassembles multiple >>>>>>>>>>> messages >>>>>>>>>>> into one. I think I may know how to do this, but the document >>>>>>>>>>> should >>>>>>>>>>> tell me. >>>>>>>>>>> >>>>>>>>>>> S 8. >>>>>>>>>>> The following new registries are to be created and maintained >>>>>>>> under >>>>>>>>>>> the "RFC Required" registry policy as specified in [4]. >>>>>>>>>>> >>>>>>>>>>> Why did you choose RFC Required rather than Specification >>>>>>>>>>> Required? >>>>>>>>>>> This just seems to unduly put load on the ISE. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MBONED mailing list >>>>>>>>>>> MBONED@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mboned >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> --- >>>>>>>>>> tte@cs.fau.de >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> I don't think the execution is relevant when it was obviously a bad >>>> idea in the first place. >>>> This is like putting rabid weasels in your pants, and later expressing >>>> regret at having chosen those particular rabid weasels and that pair >>>> of pants. >>>> ---maf >>>> >>>> _______________________________________________ >>>> MBONED mailing list >>>> MBONED@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mboned >>> >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- [MBONED] Eric Rescorla's Discuss on draft-ietf-mb… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda