Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Thu, 25 January 2018 23:09 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 C351012EAE5 for <mboned@ietfa.amsl.com>; Thu, 25 Jan 2018 15:09:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, 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 TH9BMIEIEcHL for <mboned@ietfa.amsl.com>; Thu, 25 Jan 2018 15:09:39 -0800 (PST)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 ABC0112EAF2 for <mboned@ietf.org>; Thu, 25 Jan 2018 15:09:39 -0800 (PST)
Received: by mail-yb0-x229.google.com with SMTP id z90so3695140ybh.11 for <mboned@ietf.org>; Thu, 25 Jan 2018 15:09:39 -0800 (PST)
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=WhcUP1OxcMrQLg4UvDims8jZOJPcBQN6llwvuBWp//Y=; b=peg0BLoVfBjsFj28drAaHo4fJsKIxHM5uv4hCMZ97hhMCm3oX/s79UQ8TX97B1pehV l4Tsk4RRV4DTturttOftx0ZJs6oCSD30BfIaI/RZ7XUyLYAlsgJn+KTrtYHjsHP4+OaP XIFmkvq3aWRIuHaG9dE1djljMuZxhej3IaNuhATiZWxWyQ1gLAiB3VE4zkEKJFkkek3R Z1Q49EjHg3re6nlrt3Egn95dMw/cCGXDyDh78mFSDV2KYupkdazcPAjWxhnl2sysk3lv RDDkJvu5/JCjgMEH9LkANl0h+5fxHr58MNayiieEDH4umm8fTetiI3JKp72tR0tT/+i7 hJcw==
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=WhcUP1OxcMrQLg4UvDims8jZOJPcBQN6llwvuBWp//Y=; b=csaJoEt9WJUTkq4DpFRnn+JIt/0qBaknf/weMYa+IhlLcVX7svYLB9cY9vHWjb3B+d 6pgUGvna6Tabz8FdXTRgWt1YYEg7oO4HJ/RD9F2O8GY5v3TyVqkSoDqgENJL8GqtdHpa kFyxJmRR2FQU9x8xf2lZjYgfI8BJd3qX/7A08ZSFIzjL7iOaZXtv0G9P7AmSuHP4dqpv YQvQO8WnN8JfbiIhtJofgZv1ZYGzc5mzM7Q0h9bkxSOgh4XD+ubl3ua4spxlAP6DUlMm 6Uuh2LhmMEqCAvBmg2ztCsMhKiChp56XrvsV6C6IQQdOQeWiMCxjrevwRoyD2Mz89yn+ QLrw==
X-Gm-Message-State: AKwxytc2rdwzzgyfyXtRLejBUQjKjZxPBOLH3OELvV7xgOL5HO8ezhRL rfK/4Qn3bBfGQShC5hmME3dcxqOktJFjimOMUgtkCA==
X-Google-Smtp-Source: AH8x226bhssHz7Xvqyow2nI7/ht2691KeZojJVI4RkNfZAxAeKaObd4BqiVyM76M49xhPCHR30ObJf6ccI6iWxHGmk0=
X-Received: by 10.37.239.79 with SMTP id w15mr9417799ybm.293.1516921778731; Thu, 25 Jan 2018 15:09:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.201 with HTTP; Thu, 25 Jan 2018 15:08:58 -0800 (PST)
In-Reply-To: <20180125223335.GA16477@faui40p.informatik.uni-erlangen.de>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 25 Jan 2018 15:08:58 -0800
Message-ID: <CABcZeBPbCJfP=VVC6irEUtbiFuQgmMCQMEUBern=kAG-KP1SQQ@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mboned-mtrace-v2@ietf.org, mboned@ietf.org, mboned-chairs@ietf.org
Content-Type: multipart/alternative; boundary="089e0828a13cc5ff890563a1df8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/45cQ0hxJrXnDKEHdSHPA_6XzVRE>
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, 25 Jan 2018 23:09:44 -0000

On Thu, Jan 25, 2018 at 2:33 PM, Toerless Eckert <tte@cs.fau.de> wrote:
>
>
>
> > B.1) deny third-party mtrace for user devices by default
> > >
> > > | Mtrace queries SHOULD by default only be processed when sent with a
> > > source
> > > | address directly connected to the interface on which it is received.
> They
> > > | MAY additionally be filtered by the presence of IGMPv3/MLDv2
> explicitly
> > > | tracked receiver state for the indicated multicast traffic (group
> > > {,source})
> > > | from the source address.
> >
> > I think the key point here is that this is not solely about unauthorized
> > access  but also about amplification. To expand on that point, another
> source of
> > potential  amplification is to inject a Request but to lie about the
> requesting
> > address,  thus causing the final router to send a big response.
>
> 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.


(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.




> > > Give or take the wording, but would these three items if worded
> according
> > > resolve your discuss ? To re-summarize:
> > >
> > >   B.1) deny third-party mtrace for user devices by default
> > >   B.2) explicit permitting third-party mtrace only to trusted
> > >        (OAM equipment) originators
> > >   B.3) Expectation/setup of non on-path spoofing between third-party
> > >        (OAM device) query initiator and responder.
> > >
> > > C) I hate address filtering security, but given how this has been a
> > > protocol waiting for 20++ years for an RFC i don't think we should
> > > muck around with the protocol now and further delay it. Aka: as
> > > nice-to-have larger query-ids would be - is it worth doing this
> > > protocol change now given the above security model ?
> >
> > I'm not sure how long this is waiting is really that persuasive an
> argument
> > against doing the right thing. We know addresses are untrustworthy and
> > it's not like I'm suggesting you introduce real comsec between the
> > endpoints (though some form of real authentication would clearly be
> > better).
>
> If i am identifying the right part of your original email, your suggestion
> was:
>
> > 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.
>
> 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


>
> 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
>