Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Sat, 19 May 2018 22:16 UTC
Return-Path: <ekr@rtfm.com>
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 92E0F12EB0A for <mboned@ietfa.amsl.com>; Sat, 19 May 2018 15:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 FLxR0xoq3tK7 for <mboned@ietfa.amsl.com>; Sat, 19 May 2018 15:16:44 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 64B7412EB0C for <mboned@ietf.org>; Sat, 19 May 2018 15:16:41 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id c203-v6so10104103oib.7 for <mboned@ietf.org>; Sat, 19 May 2018 15:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yg85BRiyDLvR6bZ9vJMeQ4eJSTY+8sb0T6q8DNdV9kU=; b=UgMpD16/A1TJZuIqkT+3aUZoULbuBDDlIkDGF1OYi5XdgDqYfxmGN+RsObBs9INtAf Oj36bq8uckhTugMnzyhXD0zoTUUm96KIM7NTQTiFciWo2HmE7T0+lCjcxhTIOS5dsPp3 FVz/jFgqp1wRliAFtlo6qduvRarFFkvU8Hy0ZgKDv1FwqitJbWvY4jPNGjZ6uwlNXMbz kBZgUqnXHuGfmGJmzjeCe2uXPXwDZvngYC1sXGKgDQBVnL+q22R/W4GbcjXGoHz+zNG/ Yj6LeFgI9Wy0n69VReol0PQc4zoHuHRbwssecMy74/xgkxOQ4mURqxyyiWwsfzqMbGUj AbBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yg85BRiyDLvR6bZ9vJMeQ4eJSTY+8sb0T6q8DNdV9kU=; b=mLrFJr1+sEeoce8KRn6ReLRdXWZHs1sEZm/7RsQUoeDGCdtdxDIDNTaNgAIx/qGiGp fVZf+9AQ4LZ/koQOeMIQfYrpDXm9Zzog1VdFBwI6/FGWczzz08Cl5+Rc6D5KFJ2Eaj+s +nogsrkJdREHGNd7N0X1Lp6igtx4Gy4BPcHRemQy7pkqgjENtRgkcTFAQQtQbUHcBMit EG7qBlQvrDPR481QsT0hPDBMY4njqgs6NnjErt7oPkErPrnkVNrP41xTnfSnf0JkqLSw EtUMKyBhri8huok/o/vRWUgY/XIuwPUeu009c/hTQKqZ3TN4qrEt5hC0hJUT0TGCa3gz sX2g==
X-Gm-Message-State: ALKqPweawusm9EErabMJcXFQEFSzAL5pZwnp4wXxfXm7MPMtNkZQ5IU5 NepR43mKE5M649ZmtbHE2KVAZVBPkJF1TDaFvTvv9lmq
X-Google-Smtp-Source: AB8JxZrbJ39iUjiL8khvI7Xs8h3lKOcituvEoCFXsiNTu8gisGm2UQcN1hBtXyHgoDetGEDt0YfSdZw/WcVHJ2bqG/k=
X-Received: by 2002:aca:3cc1:: with SMTP id j184-v6mr8994979oia.91.1526768200666; Sat, 19 May 2018 15:16:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.118.130 with HTTP; Sat, 19 May 2018 15:16:00 -0700 (PDT)
In-Reply-To: <CABcZeBMtzsmSpeP8Ai_mBUeZq4yWjXEijE+XDnAs6W-7ukLm+g@mail.gmail.com>
References: <151628969901.2325.7724014542086691903.idtracker@ietfa.amsl.com> <36B5669F-3931-4864-9225-FF42A8B9C122@me.com> <CABcZeBPxQDBaKDpoMPiWodEEUW4+oDONJd980PR4cSyQPeQnNQ@mail.gmail.com> <80A524CD-EC4B-4539-8315-9594C6173AE5@me.com> <CABcZeBMtzsmSpeP8Ai_mBUeZq4yWjXEijE+XDnAs6W-7ukLm+g@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 19 May 2018 15:16:00 -0700
Message-ID: <CABcZeBPk4mbWqpk5m-vYaf+MAbFAhN_p8C4S+LwRM+qZTt9HaA@mail.gmail.com>
To: Kerry Meyer <kerry.meyer@me.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mboned-mtrace-v2@ietf.org, Leonard Giuliano <lenny@juniper.net>, mboned-chairs@ietf.org, mboned@ietf.org, Warren Kumari <warren@kumari.net>, Hitoshi Asaeda <asaeda@nict.go.jp>, weesan@weesan.com
Content-Type: multipart/alternative; boundary="000000000000416921056c966c18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/PmLsQCWOuKaqOSdSR8rCVZXcbeo>
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: Sat, 19 May 2018 22:16:50 -0000
I see your previous mail suggesting we do a call. That's fine too, if you want. -Ekr On Sat, May 19, 2018 at 3:09 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > > On Mon, Apr 23, 2018 at 2:10 PM, Kerry Meyer <kerry.meyer@me.com> wrote: > >> Hi Eric, >> >> Please see inline below for responses to the points raised in your most >> recent posting regarding the Mtrace V2 draft. >> >> Kerry >> >> On Apr 9, 2018, at 2:07 PM, Eric Rescorla <ekr@rtfm.com> wrote: >> >> >> >> On Thu, Mar 15, 2018 at 11:23 PM, Kerry Meyer <kerry.meyer@me.com> wrote: >> >>> Hi Eric and others, >>> >>> We are sorry for the long delay. We have been carefully considering the >>> points you have raised and how best to address them. We hope that the >>> proposed resolutions of those points will satisfy your concerns. >>> >>> Kerry >>> >>> > On Jan 18, 2018, at 7:34 AM, Eric Rescorla <ekr@rtfm.com> 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. >>> > >>> We understand that access control is required to protect against this >>> and other threats from malicious senders. This will be specified in section >>> 9.2 as follows; >>> >>> "A router MUST support a mechanism to filter out queries from clients >>> and “requests” from peer router addresses that are unauthorized or >>> that are beyond a specified administrative boundary. This filtering >>> could, for example, be specified via a list of allowed/disallowed client >>> and peer addresses or subnets for the Mtrace2 protocol port. If a query >>> or request is received from an unauthorized address or one beyond the >>> specified administrative boundary, the Query/Request MUST NOT be >>> processed. The router MAY, however, perform rate limited logging of such >>> events." >>> >> >> This seems like an improvement, but still seems to allow amplification to >> any >> client which is a valid requestor. So, if I have one such on my network, >> then >> I am subject to DoS? >> >> For valid queries/requests, we specified limiting query/request rates in >> section 9.5 as follows; >> >> "A router may limit Mtrace2 Queries and Requests by ignoring some of >> the consecutive messages. The router MAY randomly ignore the >> received messages to minimize the processing overhead, i.e., to keep >> fairness in processing queries, or prevent traffic amplification. >> The rate limit is left to the router's implementation.” >> > > This seems like the kind of thing that's going to get ignored. As a > comparison point, > consider QUIC, which forbids sending >3 messages in response to an Initial > packet. > > > > In addition, the required use of ACLs on the participating routers >> prevents the introduction of spoofed query/request packets that would >> otherwise enable DoS amplification attacks targeting an authorized “query” >> host. The ACLs provide this protection by allowing queries from an >> authorized host address to be received only by the router(s) connected to >> that host, and only on the interface to which that host is attached. For >> protection against spoofed “request” messages, the ACLs allow requests only >> from a directly connected peer and allow these messages to be received only >> on the interface to which that peer is attached. >> >> Don’t these provisions address your concern?" >> > > I'm not sure I follow where this is required. The text you are quoting > here is a lot more vague than this. Why can't "authorized" be anyone? > > >> >> >>> Additional text has been added to section 9.7 (see later in this mail) >>> to explicitly map this and other concerns to the recommended prevention >>> mechanism. >>> >>> > - 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. >>> > >>> >>> Because there are 2**16 possible query ID values, an average of 2**15 >>> forged response attempts would be required to “hit” the actual query ID for >>> a given extant query. The amount of time to do this would far exceed the >>> lifetime of an extant query/response. >> >> >> Why is that true? It's possible to send massively more than 2^15 >> messages/sec. >> >> A huge number of messages can be randomly ignored as specified in section >> 9.5. >> > > They can but they need not be. The text above is just a MAY. > > Not to put too fine a point on it, what's the problem with actually having > an ID long enough to prevent off-path attack. > > > > Even assuming that a targeted client has multiple extant queries at a >> given time, the chance of matching one is still quite small. More >> importantly, the required access control for the Mtrace protocol port >> (section 9.2, aforementioned) provides protection against an unauthorized >> malicious sender injecting bogus request packets. >> > > How does this protect against forgery to a client. > > To “guess” a query ID and client port would require a rapid burst of trial > and error packets which would be rendered harmless by the recommended use > of rate limiting. > > > It doesn't render it harmless, it just reduces the chance of success. > > > >> > - Anyone on-path can forge responses. >> > >> The forger would need to match the query ID and the dynamically allocated >> client (source) port (REF: section 3.2.1) to create a valid reply message >> that would pass validity checks at the client. >> > > Yes, but if you are on-path you know all this stuff. > > > If a malicious sender knows the query ID and client port of an extant > query because it is “on path”, then using a bigger query ID wouldn’t help. > In addition, this information could only be seen by the routers and > switches within a user’s network. Is there some practical scheme that can > and should be implemented to protect against this type of attach > originating from routers and switches within the network of a querying > client? > > I don't know if it's practical or not, but typically we would > cryptographically protect the values. As I said, this may be impractical, > but at minimum your security considerations need to adequately document > this attack and why you can't protect against it. > > -Ekr > > -Ekr > > >> > 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. >> > >> The requirement to specify a list of “trusted” clients (section 9.2) >> provides a mechanism to avoid the dissemination of this information to >> unauthorized hosts. >> >> > 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. >> > >> Agreed. The requirement to restrict the addresses permitted to send >> Mtrace messages to a given router is specified in an expanded version of >> section 9.2. >> > >> > ---------------------------------------------------------------------- >> > 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? >> > >> The word “the” preceding “LHR ...” has been changed to “an”. >> > >> > 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” >> > >> The words “It is” have been removed from the cited paragraph and other >> similar adjacent paragraphs. >> > >> > 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"/ >> > >> > >> These two cases have been combined to reflect the fact that there is no >> difference in handling. >> >> “If an implementation receives an unknown TLV type for any TLV in a >> message, it SHOULD ignore and silently discard the entire packet.” >> >> > >> > 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. >> > >> The paragraph has been modified based on this comment as follows; >> >> “An Mtrace2 Query is originated by an Mtrace2 client which >> sends an Mtrace2 Query message to the LHR. The LHR modifies only >> the Type field of the Query TLV (to turn it into a “Request”) >> before appending a Standard Response Block and forwarding it upstream. >> The LHR and intermediate routers handling the Mtrace2 message when >> tracing upstream MUST NOT modify any other fields within the >> Query/Request TLV. Additionally, intermediate routers handling >> the message after the LHR has converted the Query into a Request >> MUST NOT modify the type field of the Request TLV. If the actual number >> of hops is not known, an Mtrace2 client could send an initial Query >> message with a large # Hops (e.g., 0xff), in order to try to trace the >> full path.” >> > >> > 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? >> > >> The paragraph has been modified to clarify this point. >> >> > >> > S 3.2.6. >> > >> > 0x01 # of the returned Standard Response Blocks >> > >> > Nit: Do you want to say 0x0001 >> > >> Done, thanks. >> >> > 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. >> > >> This section is located where it is because of the sequence of >> operations: Query->Request->Reply. >> > >> > 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. >> > >> The paragraph has been expanded based on this comment as follows; >> >> "When the NO_SPACE error occurs, as described in Section 4.2, a router >> will send back an Mtrace2 Reply to the Mtrace2 client, and continue >> with a new Request (see Section 4.3.3). 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 by collating the augmented response >> blocks of subsequent replies sharing the same query ID, sequencing >> each cluster of augmented response blocks based on the order in >> which they are received." >> > 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. >> > >> > >> Agreed. The sentence has been modified based on this comment. >> >> ****** >> Addtional Note: >> >> According to above considerations, we added a new section 9.7 as shown >> below; >> === >> 9.7 Specific Security Concerns >> >> This subsection describes some of the specific security concerns and >> exposures that have been considered during the design of the Mtrace2 >> protocol. Where applicable, the exposures are mapped to the >> corresponding remedy listed in the previous subsections. >> >> 9.7.1 Request and Response bombardment >> >> A malicious sender could generate invalid and undesirable Mtrace >> traffic to hosts and/or routers on a network by eliciting responses to >> spoofed or multicast client addresses. This could be done via forged >> or multicast client/source addresses in Mtrace Query or Request >> messages. The recommended protections against this type of attack are >> described in sections 9.1, 9.2, 9.5, and 9.6 above. >> >> 9.7.2 Amplification attack >> >> Because an Mtrace Query results in Mtrace Request and Mtrace Reply >> messages that are larger than the original message, the potential >> exists for an amplification attack from a malicious sender. This >> threat is minimized by restricting the set of addresses from which >> Mtrace messages can be received on a given router as specified in >> section 9.2. >> >> 9.7.3 Leaking of confidential topology details >> >> Mtrace queries are a potential mechanism for obtaining confidential >> topology information for a targeted network. Sections 9.2 and 9.4 >> describe required and optional methods for ensuring that Mtrace >> information is not disseminated to unauthorized hosts. >> >> 9.7.4 Delivery of false mtrace information >> >> Forged “Reply” messages could potentially provide a host with >> invalid or incorrect topology information. This threat is mitigated >> by the following factors: >> >> - The required filtering of permissible source addresses specified >> in section 9.2 eliminates the origination of forged replies from >> addresses that have not been authorized to send Mtrace messages >> to routers on a given network. >> >> - To forge a Reply, the sender would need to somehow know the >> associated two byte query ID for an extant Query and the >> dynamically allocated source port number. >> === > > > >> >
- 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