Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Hitoshi Asaeda <asaeda@ieee.org> Wed, 14 March 2018 01:53 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 1AB6E1205D3 for <mboned@ietfa.amsl.com>; Tue, 13 Mar 2018 18:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] 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 0yp3j17ijjzz for <mboned@ietfa.amsl.com>; Tue, 13 Mar 2018 18:53:21 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 3F8A8124BFA for <mboned@ietf.org>; Tue, 13 Mar 2018 18:53:18 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id h19so726710pfd.12 for <mboned@ietf.org>; Tue, 13 Mar 2018 18:53:18 -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=uwf+zUdGE3muPa6OJSVBg/pMLoSu9uPJvL6ktMCqt4k=; b=pLjfZv2djwQJ+NtylMrKuDyiWbHX5t8S03lAOGlNjEYIwYQd5qbOo7lJ5462YiTLJC WkK6BTMuhvaYJeil03Ac8Rr2eyz0tmJOgQ2VokoXrGuUtkt5jVgSxK26zCJ8hlqC1Tmk f0DIrTFB/Mtd8mAOILC8iHHQvjH60cAgm10r9VXkYSlF+GmoipvyRhVKYbRhd5csYPK/ AE1k2AXTEqhsoEPAXK9RdjAqaCInOtNxzN0rqRfno+IAE9Jp9qUWMVrsrcphrKYitTrG yxgZtJFoUaPwV40BUxwSEHAua7g5zyhxNS/pXjQmRlwBvPuDrrREMyDTjgM1tLPslEs+ 72tA==
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=uwf+zUdGE3muPa6OJSVBg/pMLoSu9uPJvL6ktMCqt4k=; b=naYidBYH4uMc5EUk4do5EynAq1embx2rak12Vba6gHKRZlC6JXRR4XsfhtjdpQzTdO GjE+gXXrRYybmHzpUP54kBS4eQ9juNirwk682cylAucFjciiMryZ+cRP5DXfkwc6Bzvn u4Iz5wCWUum4S5BQ68uDDzEikaf7RcCTzC8fZcG/N9rMkoPNJ5oVG5gaaYDTmlDxHxDZ Er26jj8KVcouwGRDCbz8UWzxiRILo0y5FqDI8dAoXDEnjVMCNG4i8Ls1zZ0/WcS3e2UJ QNYeWMKpTrkyA/+q8If+4BkkYrGcgUNhrjIls4bJWZoWqQeaOSsNePsuECqmACgIPoEx Taaw==
X-Gm-Message-State: AElRT7HoifOe+2Mk1+hr7Wq581Ay0GZwpJrnxSQP8EOxk6DEmwEmBdUN /KniSR1M1HEW9kjrIRxPz3e50w==
X-Google-Smtp-Source: AG47ELs4FcDp6rc83WXaS+oI/X6RgtN1dP21qnTqHf7U+gzzKr0oFWF2jz9g5QOBTjrvoSwLFaSnPQ==
X-Received: by 10.98.57.215 with SMTP id u84mr2538520pfj.152.1520992397489; Tue, 13 Mar 2018 18:53:17 -0700 (PDT)
Received: from ?IPv6:2001:200:e103:1000:c5ff:fd0e:20a8:38d? ([2001:200:e103:1000:c5ff:fd0e:20a8:38d]) by smtp.gmail.com with ESMTPSA id x4sm2033747pgv.72.2018.03.13.18.53.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 18:53:16 -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: <CAHw9_iJBKFF_DzU3Av0TaC5+xTx6Mm6srdhWOFAsXJUY24NneQ@mail.gmail.com>
Date: Wed, 14 Mar 2018 10:53:11 +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: <6E5478D0-6145-4EC2-8DF3-15B095271F9D@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>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/4qDB4vPp-UbNSgcUY3erheOTVMI>
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: Wed, 14 Mar 2018 01:53:24 -0000
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