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
>